A runtime, not a policy document.
Governance documents describe what should happen. They can't stop an agent from calling the wrong tool at 2am. Real agent safety lives at the call site — a fast check between the agent and every action it takes, with a tamper-evident record of what it decided. If the check is slow, people switch it off; so the engineering goal is enforcement that's cheap enough to always be on.
Most "AI governance" today is a document. A policy that says agents must be supervised, data must be handled correctly, actions must be logged. It's necessary — and it's not enough. A PDF has never once prevented a piece of software from doing the wrong thing. The gap between policy as written and policy as enforced is where incidents live.
Where enforcement has to be
An AI agent is dangerous at exactly one place: the moment it takes an action — calls a tool, hits an API, writes a record, sends a message. Everything before that is reasoning; only the action has consequences. So that's where the control belongs: at the call site, on every single call.
Put a thin layer between the agent and the systems it touches. Every time the agent tries to act, that layer asks: is this allowed, for this agent, in this context, right now? Four things happen there:
- Policy check — is this action permitted by the rules for this agent and task?
- Injection scan — does the input or instruction look like a manipulation attempt?
- Capability gate — does this agent even hold the right to call this tool?
- Audit — record the decision, tamper-evidently, before the action proceeds.
Why latency is a security property
Here's the part teams miss: if the check is slow, it gets disabled. A security control that adds noticeable lag to every agent action becomes the thing an engineer turns off under deadline pressure. The most secure design in the world provides zero protection once it's commented out.
So the overhead budget isn't a performance nicety — it's a security requirement. The check has to be fast enough that nobody has a reason to remove it. That constraint shapes everything: deterministic policy evaluation over slow model calls, in-process over network round-trips, simple rules that resolve in microseconds. The target SecuRight designs to is a sub-20-millisecond check — fast enough to stay on, on every call.
Why the audit has to be tamper-evident
A log you can edit after the fact is not evidence. For an agent operating in a regulated environment, the value of the audit trail is precisely that it can be trusted — that what it says happened, happened, and hasn't been altered. An append-only, tamper-evident log means an incident review, a compliance audit, or a post-mortem starts from a record everyone can rely on.
It also changes the conversation with a reviewer or auditor. "We log agent actions" invites the question "and how do we know the log is complete and unaltered?" A tamper-evident design answers it structurally.
Policy and runtime are complements
None of this replaces governance documents — it gives them teeth. The policy says what's allowed; the runtime enforces it at the point of action and proves it did. Write the policy, then make it executable. That's the whole idea: security as a runtime, not a runbook.
This is the architecture SecuRight is building toward. It's in development; this writing is where the design gets worked out in the open.