The AI safety conversation is dominated by guardrails. Content filters, output classifiers, refusal training, red-teaming — all of it designed to prevent AI from saying or doing the wrong thing. For chat interfaces, this is the right focus. For AI agents with real API access, it's insufficient.
The problem is category. Guardrails address what the model outputs. But when an AI agent has access to your APIs, the dangerous surface isn't the text it generates — it's the actions it takes. And actions have consequences that no downstream filter can undo.
The sequence matters
A guardrail that catches a harmful action after the agent decides to take it is better than nothing. But between the decision and the catch, the action may have already started executing. API calls don't have a universal 'cancel' button. An email sent is an email sent. A record updated is a record updated.
The only reliable way to prevent an action is to make it impossible before the decision is made, not to intercept it after. That requires a different architecture — one where the agent's possible actions are defined before it starts, not adjudicated after it finishes.
Guardrails are hard to maintain comprehensively
Writing a guardrail means anticipating every harmful thing an agent might try to do and writing a rule to block it. That's an adversarial, never-ending task. Your API surface changes. New tasks get added. Edge cases appear that nobody thought of. The guardrail has to keep up with all of it.
A registry flips this. Instead of listing what's forbidden, you list what's allowed. Anything not on the list is blocked by default — no rule required. The maintenance burden is registering new tasks as you intentionally expand the agent's capabilities, not chasing down every possible misuse.
For compliance, intent isn't enough
Guardrails express intent. A policy that says 'don't access customer payment data without authorization' is an intent. Proving to an auditor that the intent was enforced is a different problem entirely. You need to demonstrate not just that you tried to prevent unauthorized access, but that unauthorized access was structurally impossible.
A registry with typed task definitions, combined with auth isolation and an audit log, gives you that proof. The agent couldn't have accessed payment data through an unregistered route because no unregistered routes exist. That's a structural guarantee, not a best-effort policy.