Agentic AI Security: Risks and Runtime Controls
Agentic AI security is the discipline of controlling what autonomous agents can call, which credentials they hold, and how their actions are recorded. This guide maps six agent-specific risks to OWASP guidance and to the runtime controls an AI gateway enforces.
TL;DR
- Agentic AI security covers the risks that appear when an AI system can call tools, spend money, and delegate work without a human approving each step.
- The six agent-specific risks are excessive agency, tool misuse, prompt injection through tools, agent-to-agent trust, credential sprawl, and untraceable actions.
- The OWASP Top 10 for Agentic Applications, published in December 2025, includes tool misuse, identity and privilege abuse, and insecure inter-agent communication.
- A gateway in front of models, MCP tools, and peer agents can enforce identity, deny-by-default tool access, guardrails, budgets, and logging in one place.
- Bifrost covers all three paths in one gateway: the LLM gateway, the MCP gateway, and the recently launched Agent Gateway for A2A calls.
Agentic AI security is the practice of controlling what autonomous AI agents are allowed to call, which credentials they carry, and how every action they take is recorded and attributed. Bifrost, the open-source AI gateway for models, tools, and agents built by Maxim AI, applies those controls at runtime for enterprise teams by placing one policy layer between agents and everything they can reach. This guide defines agentic AI security, covers the risks specific to autonomous agents, and maps each to a gateway control.
What Is Agentic AI Security?
Agentic AI security is a set of runtime controls that limit what an autonomous agent can do, verify who is asking it to act, and record what it did. It extends LLM security from protecting prompts and responses to governing tool calls, delegated tasks, credentials, and spend, because an agent's output is an action rather than text.
Three properties make agents harder to secure than a model call: autonomy (loops run before anyone reviews them), reach (a model error becomes a system change), and delegation (each hop can widen or lose the caller's identity). The question shifts from "is this response safe to show" to "should this call execute at all."
An agent reaches three kinds of upstream systems: model providers, tool servers exposed over the Model Context Protocol, and other agents. Each path needs identity, scope, content inspection, and logging. Figure 1 shows the layer where those controls can be applied once for all three.
Figure 1: Agents reach models, tools and other agents through three separate paths, and the gateway is the one layer that sees all three.
The OWASP Top 10 for Agentic Applications
The OWASP Top 10 for Agentic Applications is a peer-reviewed list of the most critical security risks for autonomous AI systems, released by the OWASP GenAI Security Project on December 9, 2025 and developed with more than 100 industry experts, researchers, and practitioners. It is a practical reference for scoping agentic AI security work, and the AI agent security platforms roundup compares the tools built against it.
The OWASP Top 10 for Agentic Applications runs from ASI01 Agent Goal Hijack to ASI10 Rogue Agents, and includes Tool Misuse, Identity and Privilege Abuse, Memory and Context Poisoning, and Insecure Inter-Agent Communication. Memory poisoning and unexpected code execution also need controls inside the agent runtime. The companion guide on the OWASP LLM Top 10 at the gateway covers the model-level list.
| Agent-specific risk | Closest OWASP reference | Runtime control at the gateway |
|---|---|---|
| Excessive agency | LLM06:2025 Excessive Agency | Deny-by-default tool allow-lists per key; no tool auto-executes unless listed |
| Tool misuse | ASI02 Tool Misuse | Guardrails on tool arguments before execution; budgets and rate limits |
| Prompt injection through tools | ASI01 Agent Goal Hijack | Guardrails on tool results before they return to the model |
| Agent-to-agent trust | ASI07 Insecure Inter-Agent Communication | Per-agent grants, rejection of anonymous calls, separate agent and tool access |
| Credential sprawl | ASI03 Identity and Privilege Abuse | Virtual keys, gateway-held upstream credentials, caller credential removed by default |
| Untraceable actions | ASI10 Rogue Agents | Request logs, Agent Logs with recorded caller, signed audit logs |
Excessive Agency and Tool Misuse
Excessive agency is the condition where an agent holds more tools, permissions, or autonomy than its task requires. Tool misuse is what follows: a legitimate tool used for a harmful purpose. Both are contained by shrinking the default, so an agent starts with no tools and gains only the ones its job needs.
The OWASP guidance on Excessive Agency (LLM06:2025) names excessive functionality, excessive permissions, and excessive autonomy as its typical root causes.
Bifrost applies MCP tool filtering at three stacked levels: the MCP client configuration, request headers, and the virtual key. A tool must pass every filter to be offered to the model. A virtual key with no MCP configuration gets no tools, except from clients an admin has marked Allow by Default.
When a caller sends its own x-bf-mcp-include-tools header, Bifrost narrows it to the key's per-key tool allow-list, so a header can only remove tools, never add them. The allow-list is enforced again at execution time, and inactive or expired keys are rejected with a 403.
Autonomy is a separate setting. In Agent Mode, no tool runs automatically unless it is listed in tools_to_auto_execute; every other tool call returns to the application for approval. Budgets and rate limits on each key cap what a looping agent can consume.
Indirect Prompt Injection Through Tools
Indirect prompt injection is an attack where instructions are hidden in content an agent reads, such as a web page, a ticket, or a tool result, rather than in the user's prompt. For agents it is the most direct route to goal hijack, because the injected text arrives through a trusted tool channel and can steer the next tool call.
Filtering only the user's prompt misses this path; the tool boundary must be inspected in both directions, as Figure 2 shows.
Figure 2: Each check can stop the call before the next one runs, so an injected instruction has to pass identity, scope and content checks before any tool executes.
Bifrost guardrails support an mcp target alongside the llm target. A rule set to run before the tool call inspects arguments and can block execution; a rule set to run after inspects the result and can withhold or redact it before the model sees it. CEL rules can match on the MCP client, tool, and arguments.
Bifrost-managed profiles include Secrets Detection for leaked credentials, Custom Regex for PII patterns, and Prompt Guardrails, an LLM-as-judge for natural-language policies. External providers such as AWS Bedrock Guardrails and Google Model Armor link to the same rules.
The guardrails overview covers rule design, and the prompt injection defense guide covers attack patterns in depth.
Agent-to-Agent Trust and A2A Security
Agent-to-agent trust is the question of whether one agent should accept a task from another, and with whose authority it then acts. Without a control point, a peer agent cannot tell who started the chain or whether that caller was allowed.
The A2A protocol standardizes how agents exchange messages and tasks, but authorization policy is left to the deployment. Agent Gateway in Bifrost, launched on October 20, 2026, brings A2A v1 agent calls into the same gateway as model and MCP calls. Its trust controls are explicit:
- Per-agent grants. A virtual key is given access to specific agents, or an agent is set to "Allow any virtual key."
- Authentication enforcement. With
enforce_auth_on_inferenceenabled, anonymous calls are rejected. - Separate permissions. Permission to call an agent does not grant access to the models or MCP tools that agent uses.
- Credential removal by default. Bifrost strips the caller's Bifrost credential before forwarding a request to the agent.
- Blocked private callbacks. Private and internal push-notification callback destinations are blocked by default.
Figure 3: Permission to call an agent and permission to use models or tools are granted separately, and correlation headers tie both halves into one record.
For trusted agents, "Forward Bifrost authentication" lets the agent reuse the caller's credential on its model and tool calls, which then follow the original caller's access rules and budgets. Otherwise the agent uses its own key. The Agent Gateway access control settings cover both modes, and Bifrost Enterprise adds Access Profiles and Projects.
Credential Sprawl and Non-Human Identity
Credential sprawl is the accumulation of long-lived provider keys, MCP server tokens, and peer-agent credentials inside agent code, environment variables, and tool configs. Each copy is a non-human identity that cannot be traced to a person or revoked in one step.
The fix is one gateway-issued identity per agent, with upstream secrets held behind the gateway. Figure 4 compares the two arrangements.
Figure 4: Moving upstream credentials behind the gateway leaves the agent with one revocable key and puts every call in one log.
In Bifrost as the control plane, virtual keys are the primary governance entity. Each key carries model and provider filtering, budgets, rate limits, and an active status, so disabling one key cuts off a misbehaving agent without rotating a provider secret.
MCP authentication supports six types: None, Headers, OAuth 2.0, Per-User OAuth, Per-User Headers, and Token Exchange (Enterprise). Per-user types let an agent reach a tool as the user it acts for, not through a shared service account. The governance resource page shows how keys, teams, and customers fit together.
Untraceable Actions and Agent Audit Trails
Untraceable actions are agent operations that cannot be tied back to a caller, a task, or a policy decision after the fact. When model calls, tool calls, and delegated tasks each land in a different service's logs, an incident review becomes a manual reconstruction and accountability is unclear.
| Record | What it captures | Where it helps |
|---|---|---|
| Request logs | Inputs, outputs, tool calls, tokens, cost, and latency for LLM and MCP traffic | Debugging a wrong answer or a cost spike |
| Agent Logs | Messages, task updates, results, and the recorded caller for each A2A conversation | Finding who started a delegated task |
| Audit logs (Enterprise) | Administrative changes, optionally HMAC-signed, exportable as JSON, JSON Lines, or Syslog | Proving who changed a policy and when |
Request logs are captured asynchronously and can store guardrail-redacted values. Agent Logs link to model and tool calls through two headers: x-bf-session-id carries the A2A context ID and x-bf-agent-correlation-id carries the A2A task ID.
Audit logs cover the control plane, and role-based access control limits who can change policies. Tool-level logging patterns are covered in AI agent audit logs.
How to Secure AI Agents at the Gateway Layer
Securing AI agents at the gateway layer means routing every model, tool, and agent call through one control point, then applying identity, least-privilege scope, content checks, spend limits, and logging there. This baseline applies before agents reach production.
- Issue one virtual key per agent. Never hand an agent a raw provider key.
- Start every key with no tools. Add tools only as each workflow needs them, and keep destructive tools out of
tools_to_auto_execute. - Attach guardrails to the tool boundary. Add
mcprules on arguments and results, plusllmrules for prompts and responses. - Set budgets and rate limits. A runaway loop then hits a ceiling.
- Register peer agents behind the gateway. Enable authentication enforcement and grant each key only the agents it should reach.
- Route agent calls back through Bifrost. Attach the correlation headers so one record ties each conversation to its model and tool calls.
The gateway itself adds 11 microseconds of overhead per request at 5,000 RPS in sustained benchmarks, across 25+ providers and 10,000+ models. The Agent Gateway launch post walks through registering an A2A agent.
The MCP gateway overview covers the tool side, and guardrails in agent workflows covers safe fallbacks.
Frequently Asked Questions
What security risks are associated with agentic AI?
The main agentic AI security risks are excessive agency, tool misuse, prompt injection delivered through tool results, unverified agent-to-agent delegation, credential sprawl, and actions that cannot be traced to a caller. The OWASP agentic list adds memory poisoning, supply chain vulnerabilities, cascading failures, and rogue agents.
How do you secure AI agents?
Secure AI agents by giving each one a scoped identity, starting it with no tools, inspecting tool arguments and results, capping spend, and logging every call with its caller. At a gateway, one policy covers model calls, MCP tool calls, and calls to other agents instead of being rebuilt in each agent framework.
Is agentic AI security different from MCP security?
MCP security is one part of agentic AI security. It covers the tool path: which MCP servers an agent can reach, how it authenticates, and what arguments and results contain. Agentic AI security also covers model access, spend, and delegation. The guide to MCP security risks and mitigations covers the tool path in depth.
Do AI guardrails stop tool misuse by agents?
AI guardrails reduce tool misuse when they run at the tool boundary, not only on the user's prompt. In Bifrost, an MCP guardrail can block a tool call before it executes and withhold or redact a result before the model sees it. They work best alongside deny-by-default allow-lists.
Does Bifrost apply guardrails to agent-to-agent calls?
Agent-to-agent calls in Bifrost are controlled through access rather than content rules: per-agent grants, authentication enforcement, credential removal, and Agent Logs. Guardrails, budgets, and rate limits apply to the model and MCP tool calls the agent routes through Bifrost with a forwarded or agent-owned key.
What is non-human identity in agentic AI?
Non-human identity refers to the credentials that agents, services, and tools use to authenticate instead of a person. In agentic systems they multiply quickly, one per provider, tool server, and peer agent. One revocable gateway key per agent, with upstream secrets held by the gateway, keeps each identity scoped and auditable.
Getting Started with Agentic AI Security in Bifrost
Agentic AI security depends on one enforcement point that sees every model call, tool call, and delegated task. Bifrost provides that point for models, tools, and agents, with virtual keys, tool filtering, guardrails, budgets, Agent Logs, and audit logs, deployable in your own VPC through Bifrost Enterprise. To see these runtime controls applied to your own agents, book a Bifrost demo.
