How it works
To make an AI agent employable in a regulated company, you need what regulators always demanded of human staff: a role, locked doors, mandatory sign-offs, and a logbook that can't be faked. These six are your regulations, built into the software so they hold whether or not anyone follows a procedure.
An AI agent is modeled the way a regulated company models a person: it is an identity that holds exactly one role at a time. The role is the unit of authority. Nothing an agent does is anonymous, and nothing it can do is implicit — capability flows only through the role it wears.
Maps toAttributability — the ALCOA “Attributable” principle.
A role is a key ring. Each grant opens one specific door — a tool, a connector, a skill — and everything not granted is denied. Grants are versioned, so you can reconstruct exactly what any agent was permitted to do on any past date. This is the difference between a control and a fence: a tool list hard-coded by the developers who built the agent has no record of who approved it, no history, and no revocation trail.
Maps toAccess limited to what is explicitly granted; authority checks (e.g. 21 CFR §11.10(d)/(g)).
If an agent prepared the work, it is impossible — not discouraged, impossible — for that agent’s role to approve it. The separation is enforced structurally inside the run, at runtime, by construction. The attempt is refused and the refusal lands in the log. No tracker, content filter, or scoped credential can express “may prepare or approve, but never both on the same item.”
Maps toMaker-checker; quality-unit independence (e.g. 21 CFR §211.22).
A gate is a step in the workflow, not a notification bolted on afterward. It demands a quorum — n of m named approvers — and the human who requested the action can never be one of them. When a person signs, their reason is captured verbatim and bound to the decision, so the signature carries its meaning.
Maps toSignature with recorded meaning (e.g. 21 CFR §11.50).
A role carries the limits of its authority: a monetary threshold above which a human must sign, a cap on how many times a skill may fire, a budget on tokens. Limits are set and owned by the compliance side, not the developers who build the agent — and when a limit is reached, the system fails closed.
Maps toDelegated-authority limits.
Every action, every model call, every approval lands in a sealed, append-only chain. Change one record and the whole chain visibly breaks. You can export a signed evidence bundle that a regulator verifies offline — with zero access to our systems or yours — against a published, open formula anyone can reimplement. Trust does not depend on trusting us.
Maps toAudit trails and signature linking (e.g. 21 CFR §11.10(e), §11.70).
The difference
Developers do limit their agents today — they hard-code which tools an agent can call, and IT scopes its credentials. But a tool list in code has no record of who approved it, no history, no revocation trail; credentials can't express “may prepare or approve, but never both on the same item”; and the limits are set by the same people who build the agent — the doer defining its own boundaries.
Human employees have keycards too. Regulators still demanded delegation logs, signature authority, and four-eyes processes on top — because access control is not accountability. These six primitives are that layer: limits as versioned, compliance-owned grants; conflict of duty enforced at runtime inside the workflow; evidence a regulator can verify without trusting anyone.
Keep reading
See it for yourself
One command starts the demo: an agent stopped from signing off its own work, and the signed evidence file an inspector can check for themselves.
Designed against the rules your auditors already enforce.