What it is
Not a filter bolted onto a product. The layer every OBEL product is built on top of.
Most AI products add security after the fact - a moderation call here, a redaction step there, wired in wherever the team building the feature remembered to put it. ARGUS-i is the opposite: it is the thing every request has to pass through, because it sits underneath the product surface rather than beside it. OBEL Chat, OBEL Developer's CLI proxy, and the OBEL GaaS API all call the same core - the same detection logic, the same classification schema, the same policy evaluation, the same tamper-evident recording.
That matters for a simple reason: a security layer that behaves differently depending on which product you happen to be using is not a security guarantee, it is a product feature that can be missing somewhere. ARGUS-i is designed so it can't be.
Principles
Four rules that don't bend per customer, per deadline, or per outage.
FAIL-SHUT, always
If ARGUS-i cannot complete a check - a timeout, an internal error, a malformed input - the request is denied, not passed through. There is no degraded mode that quietly opens a hole under load or during an incident. Availability never overrides a governance decision.
Scrub before anything else
Detection runs before classification, before policy evaluation, before a model or downstream system ever sees the content. Nothing about ARGUS-i's placement in the request path is optional or reorderable per caller - it is the first thing that happens, every time.
Every decision is evidence
A detection hit, a classification result, and a policy outcome are not just applied - they are written to a tamper-evident record before the request completes. The governance decision is provable after the fact, not just trusted in the moment.
One engine, not a fork per product
OBEL Chat, OBEL Developer, and OBEL GaaS all call the same ARGUS-i core. There is no lightweight version for one surface and a full version for another - a scrub result from the GaaS API and a scrub result from the chat interface come from identical detection logic.
Capabilities
Four functions, always run in the same order.
Detection & Scrubbing
- Identifies personal information, government identifiers, financial data, and credentials in text before it reaches a model or a downstream system
- Replaces detected content with typed placeholders - the receiving system never sees the original value
- Tuned against real-world data shapes, not a fixed demo pattern set - detection rules are extended and re-tuned continuously
- Runs as pure, dependency-free logic with no external service call in the hot path - nothing to time out, nothing to leak to
Sovereign Classification
- Assigns a protective marking to every interaction, aligned to the PSPF schema: UNOFFICIAL through TOP SECRET
- A configurable ceiling per organisation hard-blocks content above the approved level - inference or storage never happens above that line
- Classification is re-evaluated at retrieval time as well as ingest time, so a policy tightened after the fact still applies to old content
- The schema itself is version-locked per release - a classification decision from six months ago is reproducible today
Policy Enforcement
- Rules are matched against the type of event, its assessed risk, and the kind of resource involved - the most specific applicable rule wins
- An organisation without custom rules falls back to a simple risk-based threshold, so policy is never silently absent
- Effects are enforced server-side - allow, warn, block, or route to human approval - not left to the caller to honour
- Policy configuration is per-organisation and does not require a code change or a deploy to update
Tamper-Evident Recording
- Every detection hit, classification decision, and policy outcome is committed to an append-only, hash-linked record
- The chain can be independently recomputed and verified from stored content - it is not a flag that says 'trust us'
- Recording happens inline with the decision itself, not as a best-effort log written afterward
- Records are attributable to the specific organisation and key that generated them, with no cross-tenant visibility
Where it runs
Three products. One engine underneath all of them.
OBEL Chat
Every message a user sends, and every response a model returns, passes through ARGUS-i before it reaches the other party.
Learn more →
OBEL Developer
Claude Code, Aider, Gemini CLI, and Goose all route through the same detection and classification pipeline via the CLI proxy.
Learn more →
OBEL GaaS
The same engine, exposed as an API - scrub, classify, and enforce policy against your own platform's traffic.
Learn more →
A note on transparency
Detailed about what ARGUS-i does. Deliberately quiet about exactly how.
We publish the parts of ARGUS-i that let you evaluate it - the architecture, the guarantees, the order of operations, the failure behaviour, and the schema it classifies against. We don't publish the specific detection rules, matching thresholds, or internal scoring logic, for the same reason a bank doesn't publish its fraud model's exact decision boundary: detailed knowledge of a detector's internals is exactly what someone would need to construct content that slips past it.
What is public and independently checkable is the audit ledger's hash-chain algorithm - because a governance record you can't verify isn't worth having, and verifying a chain of hashes doesn't tell an attacker anything about what triggers a detection in the first place. Where those two goals conflict, we publish the guarantee and keep the mechanism internal.