AI agents are autonomous operators, accessing applications, retrieving data, chaining tools, and executing tasks across within and external to the organisation. Giving these AI agents broad access to tools and APIs, however, provides them with operational reach across the whole environment and unless this is carefully guided, that reach can see the attack surface quickly grow.
To safeguard access and authenticate AI agents, accepted best practice is to use a secure AI gateway or something similar that integrates with the enterprise Identity Platform (IdP) which provides a record for permissions and privilege information. This integration can help limit what an AI agent, working on behalf of a credentialed employee, can and can’t do. However, what we’re seeing in practice is that identity alone does not solve the problem.
Identity tells you who has access to applications and data, but it doesn’t tell you the scope of access and agents are already going beyond their scope and performing actions they shouldn’t. For example, news recently surfaced of an AI agent in a research project was recently caught mining crypto despite not having received an explicit instruction to do so.
Agents run amok
Traditional role-based access (RBAC) doesn’t work for AI agents. This is because the agent once identified and authorised can then carry out autonomous actions within their remit but that runs contrary to the best interests of the business.
Perhaps an employee with read/write access to a CRM and billing system uses an AI agent to summarise customer support tickets and draft responses. The agent inherits the employee’s credentials, passes every IdP gate, and gets to work but then encounters a ticket mentioning a refund dispute. Instead of flagging it for human review, it calls a billing API to adjust the account balance. The employee never asked for a financial change, but the agent had the authority, the tools were available, and the model took action. Identity worked. Authorization worked. But privilege scoping at the agent level did not exist.
What’s needed is a way to restrict the tools provided to the agent so that their scope reflects the intended task. Their permissions are then broad enough to fulfil the request but narrow enough to contain its actions. When we don’t address that scope and restrict agent actions, we risk agents being able to reach data and systems they have no business touching, creating a sprawling, expanding attack surface, not to mention the operational, cost, and performance problems that arise.
Future failings
The future problems that could come back to bite us include a massive potential blast radius when an agent ‘misbehaves’ because every tool definition loaded into an agent’s context is a callable API endpoint and the more tools that are exposed, the wider the impact. Those tool definitions consume tokens regardless of whether the tool is used or not and so that then leads to wasted resource and higher costs. Plus, having a wealth of tools to choose from can overwhelm agents, leading to poor choices about which tool to use. That can also result in redundant API calls and increase the risk of hallucinations. Overtime, failing to nail down agent access typically leads to MCP server sprawl. That’s because teams or employees are likely to stand up slightly different servers to meet their needs which still connect to the same API, resulting in a glut of similar MCP servers that IT then has to manage.
The problem of how to control tool use is something AI model providers have already been grappling with. Anthropic recently introduced a tool search capability that lets Claude dynamically discover and load tools rather than stuffing every tool definition into the context window. It reduces token overhead and helps the model focus on relevant tools for a given task. But it’s fundamentally a tool search and a performance optimisation solution – not a security control. The LLM still decides which tools to use based on its own volition and there’s no policy enforcement, admin-defined boundaries, or audit trail of what was made available versus what was used. It’s also specific to Anthropic, so won’t provide governance over other LLMs.
In contrast, introducing controls that sit at the infrastructure level, between agents and the tools they call, regardless of model, helps address the issue and it’s here where the concept of Agent Personas helps. An Agent Persona defines a single virtual MCP endpoint that is scoped to reflect only the tools that agent needs to carry out its mission across multiple applications and MCP servers.
How Agent Personas work
In practice, the agent points to a single virtual MCP endpoint served by an AI Gateway. Behind that endpoint, the gateway works like an LLM, using NLP prompts to select the right tools for the job from across all of the connected applications and MCP servers. But the agent sees just one MCP server, and the AI gateway handles the rest. If needs change and the agent needs to be given a different task to perform, the Agent Persona is simply updated in the Gateway, requiring no code changes, reconfiguration or the creation of yet another MCP server.
But what happens when those agents are headless or non-interactive agents, such as those that run inside CI/CD pipelines, or that schedule automation workflows, batch processing jobs, and background orchestration tasks? Not all agents run tasks on behalf of a human operator, and these agents don’t authenticate through an IdP.
In these instances we need a purpose-built credential purely for AI agents that isn’t just an API token. It needs to be composite credential that examines three aspects: the agent’s identity (which agent is this?), the user’s identity (on whose behalf is it acting?), and the persona’s privileges (what is the agent allowed to do). By creating such an Agent Access Key, it then becomes possible to ensure these autonomous agents are authenticated, scoped, and attributable down to the human, agent, and permission.
Putting Agent Personas in place helps prevent the nightmare of unchecked tool access and MCP server sprawl. Personas effectively create least privilege access that is purpose-built for autonomous AI and keeps context lean, decisions accurate, and access controlled by design. And Agent Access Keys promise to provide us with capabilities to instruct an agent and record its activity so we know that agent “X”, on behalf of user “Y” and using persona “Z”, called tool “W” at timestamp “T”; details that make the difference between a forensic dead end versus a five-minute root cause analysis for the security or compliance team. In effect, this means the question is no longer should we apply least privilege access to agents but can we afford not to?
