Autonomous AI agents are no longer theoretical. They're running in production systems across organisations right now, executing tasks, accessing data stores, and calling APIs with minimal human intervention. Yet most infrastructure and security teams treat them as a policy problem rather than a technical one. That framing obscures a deeper issue: agentic AI introduces attack surfaces and failure modes that traditional monitoring and access control frameworks weren't designed to catch.
The Execution Gap
When you deploy a traditional application or service, you control its entry points. A web application has defined endpoints; a scheduled job has a cron rule; an API consumer has documented scopes. But an autonomous agent operates differently. It makes runtime decisions about which APIs to call, which data to fetch, and what actions to take based on dynamic prompts and context. This means the actual blast radius of the agent's access isn't fixed at deployment time—it's determined by what the agent's instructions tell it to do.
Consider a support agent that's supposed to retrieve customer account summaries and respond to queries. In theory, it needs read access to customer records and the ability to post replies. But during execution, if the agent misinterprets a prompt, gets confused by an edge case, or follows a chain of reasoning that wasn't anticipated, it might attempt to modify records, escalate privileges, or call administrative endpoints. The agent's security model is typically either "grant it broad access and trust the prompt," or "lock it down so tightly that it becomes useless." Neither option actually solves the problem.
Logging and Attribution Become Murky
Infrastructure audit logs expect clear cause-and-effect: a user issued a command, a service processed it, a database recorded the change. With agentic AI, that chain fractures. The agent received a natural-language instruction—possibly from a user, possibly from another system—and decided to take action. If something goes wrong, was it a mistake in the prompt, a flaw in the agent's reasoning, a compromised input channel, or a genuine security breach? Standard SIEM rules and log analysis tools weren't built to trace multi-step agent reasoning and detect anomalies in decision-making, only in raw API calls.
This creates a blind spot: an attacker who can influence an agent's input (a prompt injection, a crafted email that gets fed to the agent, manipulated context data) can potentially cause the agent to take actions that look like legitimate operations in the audit log. The agent is following its instructions. The API calls are being made by an authenticated service. But the agent was steered toward something harmful.
Access Control Models Fall Short
Role-based access control, attribute-based access control, and least-privilege principles all work on the assumption that you can define what a service should be able to do before it runs. You grant a service permission to read customer data, write logs, and call a payment API—then you trust that the service respects those boundaries.
Agentic AI breaks this model. An agent might need broad read access to many systems to reason about a problem, but you don't want it writing to all of them. You want it to write only in specific, constrained ways—but those constraints need to be enforced at runtime, based on what the agent is trying to do, not just what permissions it holds. That requires richer policy: not just "can this agent call this API," but "is this specific API call, in this specific context, consistent with what the agent should be trying to accomplish right now."
What Infrastructure Teams Should Do Now
Policy and governance matter, but they're not sufficient. If your organisation is running agentic AI in production, your security and infrastructure teams need to:
- Map all agentic workloads and document their data dependencies and API usage—treat them as new assets requiring audit and threat modelling.
- Implement runtime attestation: log not just API calls, but the agent's reasoning steps, input prompts, and decision outcomes so that cause-and-effect can be reconstructed.
- Design API endpoints and data stores to be resilient to unexpected access patterns; assume an agent might call them in ways you didn't anticipate.
- Use network segmentation and API rate-limiting to contain an agent's blast radius, rather than relying solely on access-control lists.
- Run regular red-team exercises: try to manipulate agent inputs and observe whether your controls catch the deviation.
The security industry is still developing tools and practices for agentic workloads. For now, the engineers responsible for hosting infrastructure, APIs, and data systems need to assume that agents will behave in unexpected ways and design systems that remain defensible even when they do.
