The five layers of AI agent security
When an agent moves from generating text to taking actions through tools and APIs, the attack and failure surfaces split into layers that fail independently:
- 1.Input security — prompt injection. Manipulated content makes the agent follow instructions its operator never gave. Defended at the model and tool-design layer.
- 2.Output security — data exfiltration. Sensitive data leaves through responses, generated files, or outbound calls. Defended with output filtering and egress control.
- 3.Credential security — exposure of keys. Raw API keys sit in prompts,
.envfiles, and project folders the agent reads, runs, and logs from. Defended by keeping the key out of agent context entirely — AI agent API key management. - 4.Action security — wrong-tenant use. The right credential used on the wrong client account. Often worse than a leak, because every call succeeds — wrong-client access in agent loops.
- 5.Audit — knowing what ran. Without a per-attempt record, you cannot answer what the agent did, with which credential, for which client.
Why one tool never covers all five
A framing many practitioners use: treat the agent as an untrusted user — give it restricted privileges scoped to the exact task, never the credentials themselves. The layers fail in different places: input security fails inside the model conversation, credential security fails in the filesystem and logs, action security fails at the API boundary. A secrets manager covers secrets at rest and nothing after it returns the value. A model-side guardrail says nothing about which tenant a key touches. Treating any single tool as "AI agent security" leaves the other layers open.
AI agent credential security
Credential security is layer 3 above, but it is worth breaking apart on its own, because "credential risk" actually covers several distinct failure modes:
- →Direct secret exposure — a raw key sitting in a prompt, a
.envfile, or a project folder the agent reads. - →Prompt-injection exfiltration — manipulated content tricks the agent into echoing a credential it holds into its output, even without a direct file read.
- →Wrong-account access — the right credential, used on the wrong client's account, often the costliest failure because every call succeeds.
- →Over-broad credentials — a key scoped for far more than the task needs, so one leak or one mistake reaches everything that key can touch.
- →Missing audit — no per-attempt record of which agent used which credential, for which client, so incidents are hard to reconstruct.
- →Unclassified destructive actions — a brokered credential can still be misused if the action it authorizes is itself irreversible (delete, archive, hard-remove); destructive actions need their own explicit policy gate, off by default, separate from ordinary read/write approval.
Runtime authorization and brokered credential use address the first four: the agent never holds the raw value (closing direct exposure and most injection-exfiltration paths for that credential), a policy check runs before every use (closing wrong-account access and constraining over-broad scope to approved actions only), and every attempt is written to a redacted log (closing the audit gap). This is the credential broker pattern applied to the credential-security layer specifically.
Outloop does not claim to solve all five layers of AI agent security. It solves the credential routing, runtime access, workspace separation, account pinning, audit, redaction, and destructive-action-gate layer — prompt-injection detection and output filtering remain separate controls.
Where a runtime access layer fits — and where it doesn't
A runtime access layer covers layers 3, 4, and 5: the agent requests an approved action instead of holding a key, tenant policy blocks wrong-client use before any backend call, and every attempt is written to a redacted local audit log. That is the slice Outloop owns — and the honest boundary of it: Outloop does not detect prompt injection, filter model outputs, or replace your vault. It assumes you keep a vault for storage and adds control over runtime use, which for multi-client agent teams is where the practical risk concentrates. See the security model, the credential broker pattern, and how this plays out for AI agencies.
