AI-Agent Security
AI-agent security is the practice of controlling and protecting AI agents that can take actions through tools, APIs, files, credentials, MCP servers, and other external systems. Cirvix provides runtime authorization for those actions, evaluating each operation against policy before it executes.
What is AI-agent security?
A model answers questions. An agent causes consequences. That difference is the entire category.
An AI agent reads files, runs shell commands, calls APIs, queries databases, uses MCP tools, touches credentials, sends messages, modifies infrastructure, and triggers workflows — with your permissions, at machine speed. AI-agent security is what stands between that capability and the consequences: a control layer that decides, for every proposed action, whether the agent is authorized to cause it.
The core thesis: capability is not authority. A model being capable of executing an action does not mean the agent is authorized to cause that consequence. Frontier models keep crossing new capability thresholds, discovering novel vulnerabilities and chaining multi-step exploits autonomously. Static allowlists and prompt guardrails cannot keep up, because they evaluate text while the damage happens in tool calls. AI-agent security evaluates the tool calls.
Cirvix operates directly in the execution path: each proposed action is checked against policy before it runs, and the decision is recorded as hash-chained evidence. If the agent is compromised, tricked, or simply wrong, the boundary still holds.
Why traditional AI security is not enough.
AI security is the umbrella. AI-agent security is one category under it. Cirvix does not replace the others.
| Category | Primary job | Cirvix's relationship |
|---|---|---|
| Model security | Protect models and model infrastructure | Out of scope |
| Prompt defenses | Reduce manipulation and injection | Complementary — Cirvix assumes they can fail |
| IAM | Manage human and service identity permissions | Complementary — Cirvix enforces per-action decisions, not identity |
| Network security | Control network traffic | Out of scope — Cirvix is not a network firewall |
| AI-agent security | Protect agents and the actions they take | This category |
| Runtime agent authorization | Decide whether a specific agent action may execute | What Cirvix does |
Anyone selling you a single product that "solves AI security" is selling the umbrella as if it were one problem. It isn't. Buy model security from model-security vendors, keep your IAM, and put runtime authorization in front of every agent action.
Why agents create a new security boundary.
Every tool you give an agent is a permission. Most teams hand them out without a policy layer.
Agents execute with your credentials
A coding agent inherits cloud keys, SSH keys, SSO tokens, and repository access from whoever launched it — with no scoping, no least-privilege enforcement, and no expiration. One compromised agent is one compromised developer.
Agents chain tools into attacks
Read a file, exfiltrate it with curl, execute what comes back. Each step looks innocent; the chain is the attack. Per-tool permissions cannot see chains. A runtime boundary that watches sequences can.
Agents read untrusted content by design
Documents, emails, web pages, tool results, MCP tool descriptions — an agent's inputs are attacker-controlled far more often than a human's. Any of them can carry injected instructions the agent will follow.
Agents act at machine speed
Post-hoc detection arrives after the damage. A human review queue cannot keep up with thousands of tool calls per task. The decision has to happen before execution, in milliseconds, on every call.
Core AI-agent threats.
Stated plainly, with scope honesty: what Cirvix addresses, and what stays outside its boundary.
| Threat | What happens | Cirvix scope |
|---|---|---|
| Prompt-induced tool abuse | Injected content tricks the agent into attempting a harmful tool call | Addressed — the resulting call is still evaluated and can be denied |
| Excessive agent permissions | Agent holds broader access than its task needs | Addressed — policy scopes each action; default-deny refuses the rest |
| Credential exposure | Keys and tokens leak into prompts, logs, or tool results | Addressed — secret detection plus credential handles keep material out of agent context |
| Malicious MCP tools | A compromised tool server poisons descriptions or results | Addressed — gateway enforcement per tool call (see MCP security) |
| Tool-result manipulation | A result steers the agent toward an unsafe next action | Addressed — the next action is evaluated on its own merits |
| Unauthorized API access | Agent calls endpoints outside its mandate | Addressed — unsanctioned calls are denied |
| Filesystem abuse | Reads of secrets, writes outside the workspace | Addressed — e.g. ~/.aws/credentials reads denied by default policy |
| Privilege escalation | Agent reaches admin actions from a support-level grant | Addressed — capability bounded by authorization set |
| Delegation abuse | Sub-agents inherit more authority than intended | Addressed — each action evaluated against the issuing agent's policy |
| SSRF via agent requests | Agent is steered into requesting internal endpoints | Partially — policy can deny internal ranges; not a network firewall |
| Data exfiltration | Sanctioned reads leave through unsanctioned channels | Addressed at the action layer — egress to unapproved destinations denied by policy |
| Runaway tool sequences | Loops burn cost and hammer services | Partially — rate limiting and chain detection bound the blast radius |
| Model-level attacks | Weight theft, training-data poisoning, model extraction | Out of scope — model security territory |
For the full statement of what is defended and what is not, read the threat model. It is deliberately blunt about the gaps.
Runtime enforcement, step by step.
Agent → tool/action request → eight stages → one verdict. Every call, before it runs.
Parse
The proposed action is parsed into a typed execution event: agent, action, resource, environment, origin.
Normalize
Equivalent requests are reduced to one canonical form, so policy cannot be dodged with encoding tricks or path variants.
Secret detection
The request is scanned for credential material before anything else touches it.
Risk classification
The action is assigned a risk level. Secrets and risk resolve before policy — a rule may test risk >= HIGH, so the value has to exist first.
Policy evaluation
Deterministic rules resolve to exactly one verdict. Design target: sub-millisecond-scale authorization latency per stage budget.
Approval check
Actions held for human review wait here. Nothing executes while held.
Sanitization
Approved actions are stripped of anything the agent should not have seen or passed on.
Audit event
The decision — allow, deny, hold, or observe — enters the hash-chained audit log. Unsanctioned payload data is discarded, not stored.
Try it live: the homepage demo evaluates this exact pipeline in your browser, and the interactive sandbox lets you change a rule and watch the verdict change. The engine behind both is documented in the policy engine and architecture pages.
Allow, deny, hold, audit_only.
Four verdicts, each with a precise meaning. One of them is widely misunderstood.
| Verdict | Meaning |
|---|---|
| allow | The action may execute. The decision and its reason are recorded. |
| deny | The action must not execute. Refused calls are not counted against the free daily quota. |
| hold | The action waits for human approval. Nothing executes while held. |
| audit_only | The action is observed and recorded for policy tuning. It does NOT authorize the action — audit_only is an observation mode, not a permission. |
Default deny and fail closed.
Two properties that separate a boundary from a suggestion.
Default deny means anything not explicitly permitted is refused. There is no "probably fine" path. A new tool, a new MCP server, a new API endpoint is denied until policy covers it — which is exactly backwards from how most agent setups behave today, where everything is permitted until someone writes a blocklist.
Fail closed means the control plane refuses rather than waves through when it cannot decide safely. Over the daily decision quota, the call is denied rather than passed through unchecked. A security control that stops enforcing when a counter runs out is not a degraded product — it is an absent one.
MCP security is agent security's hardest surface.
The Model Context Protocol gives agents their tools — and every tool is a permission.
MCP servers hand agents filesystem access, shell execution, database queries, and HTTP requests behind friendly tool descriptions. Those descriptions can be poisoned. Those servers can be compromised. Broad-scope tools ("read any file", "run any command") turn one permission into all of them.
Cirvix sits between the agent and the MCP server as a policy gateway: which tools each agent may call, bounded arguments on broad tools, credential handles instead of raw secrets, and an audit record of every call. The full breakdown — tool permissions, malicious servers, least privilege, and the gateway setup — is on the MCP security page, with a hands-on path in the MCP guide and MCP demo.
Agents should use credentials without seeing them.
Secret material is not unnecessarily exposed to the agent.
Cirvix issues credential handles: the agent references a handle, the control plane resolves it at execution time, and the raw secret never enters the agent's context — where it could leak into prompts, logs, tool results, or a poisoned MCP response. On the free tier, handles are ephemeral and do not survive a restart. The mechanism is part of the execution flow, and the retention rules are stated in the security model.
Auditability, stated exactly.
Every decision leaves evidence. Here is what that evidence is — and what it isn't.
Each recorded decision is linked into a linear SHA-256 hash chain: every entry commits to the one before it, so tampering with history breaks the chain at exactly the edited point. An offline verifier replays the log with no network access.
Its properties, stated upfront: the chain is hash-linked and, since 0.1.3, optionally Ed25519-signed — each record's hash carries a signature, so a forged chain with every hash recomputed fails on the signature. There is no Merkle tree and no blockchain, and an unsigned chain still proves tampering is detectable. The honest limit: signing proves attribution to the key, not to a third party. The full mechanics are on the audit chain page.
Agent security vs prompt injection.
Read this twice. It is the most important paragraph on this site.
Cirvix does not claim to prevent prompt injection itself. It limits what a compromised or manipulated agent is authorized to do afterward.
Injection happens in text: a document, an email, a web page, a tool description tricks the model. No execution-layer product can stop a model from reading attacker-controlled text — that is the model's job, and its failure mode. What an execution layer can do is make sure the actions the tricked agent then attempts — read the SSH key, curl the exfil endpoint, run the payload — each hit a policy boundary and die there.
This is why the escape benchmark measures what it measures: not whether the agent can be fooled (assume it can), but whether the fooled agent can escape its authority. The published run data — 44 attempts, 44 blocked, methodology and per-attempt records in the repo — is reproducible rather than a marketing number.
Who needs AI-agent security?
If agents touch anything you would not hand to a stranger, you need it.
Enterprises deploying coding agents
Claude Code, Cursor, and similar assistants running against real repositories with real credentials. See the Claude Code guide and Cursor guide.
Teams using MCP
Any team wiring MCP servers into agents inherits every tool's blast radius. Start with MCP security.
AI SaaS companies and developer platforms
Your agents act on customer data with customer credentials. Runtime authorization plus an audit trail is the difference between a feature and a liability.
Internal AI automation and regulated environments
Autonomous workflows touching production systems need per-action decisions and exportable evidence — see solutions and the audit chain.
AI-agent security, asked directly.
Short answers with no marketing padding.
What is AI-agent security?
Controlling and protecting AI agents that act through tools, APIs, files, credentials, and MCP servers — evaluating each operation against policy before it executes.
How is AI-agent security different from AI security?
AI security is the umbrella (model security, poisoning, privacy, theft). AI-agent security is the category for agents that act on the world. Cirvix works in that category, specifically runtime authorization.
What is an AI agent security platform?
Software that governs what agents may do at runtime — tool permissions, data boundaries, credential use, approvals — and records it. Cirvix is a self-hosted one.
Can AI agents be hacked through prompt injection?
Yes, through any untrusted content they read. The fix at the execution layer is not preventing the trick — it is denying the harmful tool calls the tricked agent attempts.
How do you secure MCP servers?
Gateway enforcement: scope tools per agent, bound broad tools, use credential handles, audit every call. Details on the MCP security page.
How do you control what an AI agent can do?
Intercept each proposed action and evaluate it against policy before execution, with allow / deny / hold / audit_only verdicts under default-deny.
What is runtime authorization for AI agents?
The per-action permit-or-deny decision on the execution path: parse, normalize, secret-detect, risk-classify, evaluate, approve, sanitize, audit.
Does Cirvix prevent prompt injection?
No. It limits what a manipulated agent is authorized to do afterward.
Does Cirvix replace IAM?
No. IAM manages identity permissions; Cirvix decides per-action execution. They compose.
Does Cirvix inspect agent tool calls?
Yes — every call crossing the control plane, before it runs, with the decision hash-chained into the audit log.
AI agents can be compromised.
Their permissions don't have to be.
Run the free local scan with no account, or put your first agent under policy in minutes.