AI Security Best Practices for Production Agentic Systems

An agentic AI system is not a bigger application. It is an autonomous actor holding credentials, making choices, and changing its own execution path at runtime. Every control that worked for deterministic software assumes the opposite. This article walks through the infrastructure-level controls that production agents actually require.

The core mismatch is between what application security teams possess and what agents demand. A conventional firewall does not stop a prompt injection, because the attack never leaves the application layer. An API gateway does not prevent an over-permissioned agent from exfiltrating data through a legitimate tool call, because the tool call looks exactly like an authorized request. Threat models built for predictable execution paths fail when the system reorders actions, spawns sub-agents, and chains tool calls in ways no static rule anticipated.

The blast radius compounds the problem. An agent authorized to read a knowledge base, query billing systems, and modify account settings can cause exponentially more damage when manipulated than a static service account with the same entitlements, because the agent will use them in combinations no admin ever documented. Gravitee's State of AI Agent Security 2026 found that only 14.4% of organizations report all their agents going live with full security and IT approval. Governance is being drafted after production, so controls are being retrofitted onto systems that are already running.

The failure is not theoretical. In a controlled red-team exercise described by Bessemer Venture Partners, McKinsey's internal AI platform Lilli was compromised by an autonomous agent that gained broad system access in under two hours. The authoring agencies behind Careful Adoption of Agentic AI Services, including ASD's ACSC, CISA, NSA, CCCS, NCSC-NZ, and NCSC-UK, identify increased attack surface and increased complexity as agentic-specific risks that compound the inherited vulnerabilities of LLMs themselves. The security model has to change at the infrastructure layer, not the application layer.

The four categories of risk that agentic systems introduce

Agentic security risk sorts into four categories: privilege, design and configuration, behavior, and accountability. Each demands a different class of control, and conflating them is how deployments quietly fail. Privilege risks arise when agents accumulate entitlements nobody explicitly granted. Gravitee's report found nearly half of organizations rely on shared API keys for agent-to-agent authentication. Design and configuration risks are the shipping-time variant of the same disease: agents go into production with more access than the task requires. Access should exist only for the duration of a specific task, then vanish.

Behavior risks are the ones traditional application security has no category for. An agent can be steered through its inputs in ways static software cannot: prompt injection, retrieved data carrying adversarial instructions, and session drift where execution diverges from the documented task sequence. The agent is not compromised in the sense of a break-in. It is persuaded. Accountability risks complete the picture. The joint agency guidance treats accountability as a structural risk category, not a retrospective concern.

A fifth risk compounds all four: agents that spawn other agents. Each sub-agent multiplies the attack surface and inherits the parent's ambiguities. Each category has a corresponding response at the infrastructure level, which the following sections address in turn.

Least-privilege identity as the foundational control

Every production agent needs a dedicated, scoped, time-bounded identity. Not a shared service account. Identity is the only layer where access can be enforced rather than advised.

The governing principle from joint agency guidance is blunt: never give agents broad or unrestricted access, particularly to sensitive data or critical systems. Implementation means one service identity per agent role, tool access scoped to explicit allowlists, and short-lived tokens for sensitive operations that expire when the task does. Gravitee's report found only a small minority of organizations treat AI agents as independent, identity-bearing entities. The majority lump them into existing service accounts or share credentials across agents. That practice makes accountability structurally impossible, because there is no discrete audit trail and no named owner to trace an unauthorized action back to a governance decision.

The AI-GRACE framework from the University of Miami, Columbia, and Stanford, published in September 2026, formalizes this through Risk-Aligned Independence Levels, or RAIL, and an Agent Operating Envelope specifying permitted actions and escalation conditions. Memory lifecycle management belongs to the same discipline. Hard token limits on the context window prevent agents from hoarding sensitive data across sessions.

Legal pressure is arriving. The EU AI Act, effective July 2026, requires named ownership for agent identities classified as high-risk. Identity is no longer an architectural preference. It is the precondition for every control that follows.

Defending against prompt injection and runtime manipulation

Prompt injection is the most direct attack on agentic systems, and no single filter eliminates it. Defense must be layered, because each layer catches a different stage of the attack. Prompt injection ranked as the top vulnerability in OWASP's 2025 LLM Top 10. In agentic systems the risk compounds: one injected instruction in retrieved data can cascade through an entire multi-step workflow. The agent executes what it reads as instructions, and the security stack sees nothing out of the ordinary.

Structural isolation is the first defensive layer, and it closes the most direct path before any classification is needed. Retrieved content and system instructions must sit in separate architectural channels. The second line is output validation: tool call results get validated before the agent acts on them. Fine-tuning defenses are promising but not sufficient alone. The residual risk is the reason defense in depth remains the only workable posture.

Runtime monitoring serves as the detection backstop. The goal is policy and capability that lets agents deliver value while respecting security requirements, not controls that assume adversaries follow rules. One-liners cannot fix this, but the principle is practically that simple. Adversaries read your documentation too.

Zero Trust as the network-layer prerequisite for agentic workloads

Zero Trust is not an optional enhancement for agentic deployments. It is the architectural prerequisite that makes least-privilege identity enforceable across the distributed, multi-cloud environments where agents actually run. The structural driver is straightforward. Agents operate across cloud services, SaaS applications, and APIs that sit entirely outside a traditional network perimeter. A perimeter-based control has no surface to act on, which is why agents must be onboarded into the Zero Trust perimeter rather than treated as exceptions to it. Joint agency guidance lists the prerequisites before implementation: strong authentication, least-privilege principles, sandboxed environments, and threat modeling. These are not parallel workstreams to agentic rollout. They are the foundation the rollout stands on.

CISA has formally recognized that SASE solutions can replace MTIPS for federal agencies, with OT jump hosts published via ZTNA using phishing-resistant MFA, device attestation, just-in-time access, and centralized logging. The NSA's phased Zero Trust Implementation Guidelines, released in January 2026, build on the DoD Zero Trust Strategy published in October 2022 as a five-year framework. The signal is that even the most complex environments treat Zero Trust as achievable and sequenced rather than aspirational.

The execution gap remains. Most organizations do not operate from a unified platform, so policy fragments across systems and enforcement stays inconsistent. That fragmentation is exactly the condition that lets over-permissioned agents go undetected. The practical sequence most teams follow is to start with ZTNA to eliminate VPN and contain lateral movement, then expand toward full SASE as legacy connectivity decommissions. Agentic workloads should not wait for the end state. They need the identity enforcement Zero Trust enables from the first deployment.

Securing the MCP layer: governance at the protocol boundary

Anthropic introduced MCP in November 2024 as a universal interface between an LLM and its tools, using three protocol primitives: tools, resources, and prompts, all discoverable at runtime over JSON-RPC 2.0. The protocol specifies communication. It does not enforce access control. That omission makes the MCP server boundary the highest-risk point in most production agentic architectures.

On 28 July 2026, MCP maintainers shipped the largest revision since launch, making the protocol stateless at the protocol layer. Several changes invalidate threat models written against the 2025 version. MCP grants the LLM runtime ambient authority across multi-hop trust chains, which perimeter and identity controls alone do not cover. Centralized policy enforcement at the gateway level is the only mechanism that catches what those controls miss. Supply chain controls start before deployment: static application security testing and vulnerability scanning on all MCP servers, cryptographic verification of server integrity, package scanning for malware, and pinned server versions with alerts triggered on any change. Runtime isolation then contains what slips through: each MCP server in a container or VM with strict boundaries, read-only file systems by default, write access limited to explicitly designated directories, network access constrained to an allowlist of approved endpoints, and resource quotas to contain denial-of-service conditions.

None of this survives without governance. Approval workflows for new MCP servers, security baselines aligned with data classification, and centralized visibility into which servers connect to which agents are not bureaucratic overhead. Without them, MCP sprawl recreates the shadow AI problem at the protocol layer, except this time it is tool-level.

WAF, bot management, and DDoS controls for AI agent traffic

AI agents and LLM crawlers are a fast-growing share of automated traffic, and they behave enough like humans to sail past WAF rules built for known-bad signatures. The correct response is layered bot detection on top of WAF, not replacement of one with the other. WAFs detect application exploits like SQL injection and XSS through signatures, rules, and IP reputation. Modern bots rotate IPs and carry no attack signature, so they pass straight through. Behavioral anomaly becomes the only reliable detection signal.

The layered architecture splits the work. WAF handles application-layer exploits. Purpose-built bot detection sits above it, running behavioral analysis, browser interrogation, fingerprinting, and rate limiting through request tokens. For MCP-adjacent AI bot governance, rule-based approaches cover well-identified AI agents and can detect headless-browser automation, the technique agentic workflows frequently use. No single layer answers all of it, which is precisely the point.

Runtime observability: detecting when controls are failing

Agentic behavior is non-deterministic, which makes observability the only mechanism that can confirm whether preventive controls are actually holding. It is not an audit trail. It is the feedback loop the entire security posture depends on.

The confidence gap makes the stakes concrete. Gravitee's report found a large majority of executives feel confident their existing policies protect against unauthorized agent actions, while more than half of deployed agents operate without security oversight or logging. Confidence without visibility is structurally dangerous, because it means the first signal of failure is the incident itself. When an injection or privilege escalation succeeds, these are the footprints it leaves.

Observability for agentic systems must capture what a standard application log does not: agent identity, which tools it called, which data sources it accessed, what outputs it produced, any escalation events, and any sub-agent spawning. Bessemer's three-stage framework puts visibility first for this reason. Configuration and runtime protection only become possible on top of that baseline.

AI-GRACE formalizes this as an evidence requirement. Human escalation paths complete the picture. Joint agency guidance recommends defining in advance which conditions require an agent to pause and escalate rather than proceed autonomously. The two together keep the failure from compounding.

Governance structure: from agent deployment decisions to ongoing accountability

Technical controls degrade without the governance process that specifies who authorized each agent, on what scope, under what conditions, and who owns reassessment when any of those change. Security is not a deployment gate. It is an ongoing operational discipline.

AI-GRACE makes its contribution here by translating organizational objectives and obligations into qualified technical capabilities and a traceable deployment record. The output is an implementable specification of what the organization needs, what it has, and what remains unresolved. Named ownership is a prerequisite for that translation. The EU AI Act, effective July 2026, makes named ownership a legal requirement for high-risk agentic systems, which gives the governance layer teeth.

Standards provide the baseline. The NIST AI Risk Management Framework's GOVERN-MAP-MEASURE-MANAGE structure and ISO/IEC 42001's AI management system requirements are the reference points governance processes should align to, per AI-GRACE. Governance must therefore include regular access reviews against the recorded scope, not just initial approval. What a thing was allowed to do at deployment is not what it does six months later.

The MCP protocol revision of July 2026 proves why reassessment triggers matter. Governance processes must define in advance which external changes force a re-review: protocol revisions, model updates, new tool integrations, regulatory shifts. Otherwise the controls stay frozen while the system they protect keeps moving underneath them.