Announcing Agent Personas in the Cequence AI Gateway, which allow organizations and employees to manage AI agent privileges at a granular level. It provides the ability to control, monitor, and govern what an AI agent is allowed to do within a system, including data access, tool calls, system actions, and delegated authority. Agent Personas act as the AI-era equivalent of role-based access control (RBAC), but applied to autonomous agents.
Current State: AI Agents Have Too Much Access
Individual employees, teams, and organizations as a whole are rapidly creating MCP servers as a means to an end for their rapidly expanding slate of agentic AI projects. Some organizations are implementing security controls and adopting AI gateways that integrate with enterprise identity providers (IdPs), and that’s a good start. But 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 for autonomous AI agents, scope is everything.
The Keys to the Kingdom
AI agents act as autonomous operators, accessing applications, retrieving data, chaining tools, and executing tasks across within and external to an organization’s infrastructure. When you give an AI agent broad access to tools and APIs, you’re effectively giving it operational reach across your environment. Without carefully limiting that reach, the attack surface grows quickly and quietly.
Current Controls Aren’t Enough
Take authentication and authorization, for example. Ideally, you have an AI gateway or something that integrates with your enterprise IdP which acts as the system of 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, we’re already seeing agents go beyond their scope, performing actions they shouldn’t; sometimes innocently, and sometimes maliciously. For example, an AI agent in a research project was caught mining crypto to amass funds “without any explicit instruction and, more troublingly, outside the bounds of the intended sandbox.” AI agents are non-deterministic, and without proper guardrails including permission restrictions, it’s not a matter of “if” but “when” they go rogue.
The Problem with Applying Traditional RBAC to Agentic AI
Imagine an employee with read/write access to both the CRM and the billing system. They deploy an AI agent to summarize customer support tickets and draft responses. Standard permissions check out — the agent inherits the employee’s credentials, passes every IdP gate, and gets to work. During a routine workflow, the agent encounters a ticket mentioning a refund dispute. Instead of flagging it for human review, it proactively 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 inferred action. Identity worked. Authorization worked. But privilege scoping at the agent level did not exist.
Then, when the error is caught – which may be much later – the painful post-mortem begins. “Who approved this? Where are the logs? How will we make sure this can’t happen again?” So, agents having the same access to application capabilities as the employee is not acceptable. What’s needed is a way to restrict the tools provided to the agent so that their scope reflects the intended task, broad enough to fulfil the request, but narrow enough to contain it to the job they’re asked to do.
Why Existing Controls Fail at the Agent Layer
Enterprise security controls were built for human operators who exercise judgment about which tools to use and when. AI agents don’t have that judgment, and they’ll use whatever access they have if the model decides it’s relevant. Broad, unscoped tool access means agents can reach data and systems they have no business touching, creating a sprawling, ever-expanding attack surface and security exposure, not to mention operational and performance problems:
- Unbounded risk – Every tool definition loaded into an agent’s context is a callable API endpoint. The more tools exposed, the larger the blast radius when an agent misbehaves, maliciously or not.
- Costs increase – Every tool definition loaded into an agent’s context consumes tokens, whether the tool is ever used or not. Gartner notes that exceeding ~40 tools crosses a critical threshold where latency and cost increase measurably1.
- Accuracy degrades – Agents overwhelmed with tool choices make poorer decisions about which tool to invoke, leading to redundant API calls, incorrect tool selection, and increased hallucinations.
- MCP server sprawl – This has the same problem as API or microservices sprawl; teams or individual employees build slightly different MCP servers connecting to the same API, and you end up with a large number of highly-similar MCP servers. The way to solve this is through agent personas, not an unlimited number of MCP servers that IT has to manage.
Model-Level Solutions Aren’t Enough
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 up front. It reduces token overhead and helps the model focus on relevant tools for a given task. But tool search is a performance optimization, not a security control. The model still decides which tools to use based on its own inference. There’s no policy enforcement, no admin-defined boundaries, and no audit trail of what was made available versus what was used.
More importantly, enterprises aren’t building exclusively on Anthropic. Production agent stacks span OpenAI, Google, and open-source and custom models. A governance layer that only works inside one model provider’s ecosystem doesn’t solve the problem. You need controls that sit at the infrastructure level, between agents and the tools they call, regardless of which model is doing the reasoning. That’s exactly where Agent Personas operate.
Benefits of Access Control with Agent Personas
Cequence’s secure AI Gateway addresses this directly through the concept of Agent Personas. Rather than exposing an agent to every connected MCP server and all their tools, a Persona defines a single virtual MCP endpoint that is scoped to reflect only the tools that agent needs across multiple applications and MCP servers. A customer service agent gets the CRM tools it needs. A coding agent gets the GitHub and Jira tools it needs. Neither sees the other’s toolset, and neither is burdened by tools irrelevant to its task. This approach keeps context lean, decisions accurate, and access controlled by design, not as an afterthought. This is least privilege access, purpose-built for autonomous AI.
| Without Agent Personas | With Agent Personas | |
| Access Model | Agents inherit broad, identity-level access | Tool access explicitly defined per role and task |
| Security Posture | Exposure grows with every new tool and server | Attack surface minimized before execution begins |
| Agent Performance | Degrades as tool count increases | Optimized, resulting in lean context, accurate tool selection, and superior performance |
| Token Costs | Every tool definition burns tokens, used or not | Only relevant tools loaded, constraining spend |
| Governance | Policies applied after the fact, if at all | Policies enforced at the tool call level |
| MCP Management | Server sprawl grows unchecked | One gateway, curated per-persona tool sets |
How Agent Personas Work
Here’s what this looks like in practice. Say you’re building a “mini-me” agent — a personal AI assistant that handles your daily workflow. It needs to read your calendar, pull Slack threads, search Confluence, create Jira tickets, and draft emails. Until now, that meant configuring your agent with five separate MCP server URLs, managing credentials for each, and hardcoding which tools are available in the agent’s config. See how it works in action.
Agent Personas Architecture
With Agent Personas, you point your agent at a single virtual MCP endpoint served by the Cequence AI Gateway. Behind that endpoint, the gateway assembles the exact set of tools your agent needs from across all your connected applications and MCP servers. Your agent sees one MCP server, and the AI gateway handles the rest.
When your needs change — say you want to add Google Drive access, or your team spins up a new internal MCP server for a knowledge base — you don’t touch the agent, you simply update the Agent Persona in the gateway, and the new tools are immediately available to your agent the next time it connects. No code changes, reconfiguration, or redeployment of the agent itself or a new MCP server.
Agentic Management – Simplified
This decoupling is a fundamental shift. The persona definition becomes the single source of truth for what that agent can do. Security teams can add or remove tool access without requiring agent developer coordination. New MCP servers can be onboarded without breaking existing agents. And when you need to revoke access to a tool or an entire application, it’s one change in one place, effective immediately across every agent using that persona.
How It Works — Without the Complexity
Defining an Agent Persona doesn’t require mapping every API endpoint by hand. The AI Gateway’s interface works like an LLM: describe in natural language what you want your agent to do, and the gateway uses NLP to select the right tools for the job.
Under the hood, the AI Gateway:
- Brokers every call between agents and downstream applications
- Enforces IdP-backed identity alongside persona-scoped tool access
- Applies per-tool policies including rate limits, data masking, and approval workflows
- Provides full audit visibility into which agents, and which humans behind them, touched which applications and data
Built for Agentic Workflows, Not Just People
Not every agent runs on behalf of a human sitting at a keyboard. Many of the highest-value agentic workflows are headless, non-interactive agents running inside CI/CD pipelines, scheduled automation workflows, batch processing jobs, and background orchestration tasks. These agents need the same scoped access and governance, but they can’t authenticate through a browser-based IdP flow.
Agent Access Keys
That’s why Agent Personas introduce Agent Access Keys, a new credential type purpose-built for agentic AI. An Agent Access Key isn’t just an API token, it’s a composite credential that binds three things together: 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). Every tool call made with an Agent Access Key is authenticated, scoped, and attributable, down to the specific human, agent, and permission boundary.
In practice, this means you can deploy a nightly data reconciliation agent in your CI/CD pipeline with an Agent Access Key that binds it to a “Data Ops” Persona — giving it read access to BigQuery and Slack notification tools, and nothing else.
When something goes wrong — and in a world of autonomous agents, something will — you don’t just know that “a service account accessed the billing API.” You know that agent “X”, operating on behalf of user “Y”, using persona “Z”, called tool “W” at timestamp “T”. These details are the difference between a forensic dead end and a five-minute root cause analysis.
Next Steps
Cequence AI Gateway makes your applications agent-ready in minutes — securely, and without writing integration code. Ready to learn more? Request a personalized demo and let us show you.
1Gartner, Achieve Agentic AI Readiness in 4 Steps, Alex Coqueiro, Tigran Egiazarov, 5 January 2026
