AI Agent Access Control: Least-Privilege for Every Agent

What Is AI Agent Access Control?

AI agent access control is the set of policies that decide whether a given caller may reach a given resource. It answers "is this allowed," while guardrails answer "what is in it."

That distinction is worth holding onto, because the two controls fail in different ways and you need both.

• Access control is the bouncer at the door. It checks whether this agent, user, or team is permitted to call this model or this MCP tool at all.
• Guardrails are the metal detector. Once a call is allowed through, they inspect the prompt, the output, and the tool arguments for injections, PII, secrets, or unsafe operations.

An agent can be fully authorized to call your database MCP server and still be tricked into sending a destructive query. Access control said yes to the server, and only a guardrail on the arguments catches what the query actually does. Scope the access too broadly, though, and you are relying entirely on the metal detector. Least privilege is what keeps the number of allowed calls small in the first place.

The Two Levels of Access Control in TrueFoundry

TrueFoundry enforces access at two levels, and understanding the split is most of the work.

Resource-level roles (collaborators)

You add a user, team, or virtual account as a collaborator directly on a resource, and pick a role that scopes their access to that resource only. The roles are specific to the resource type:

This is where least privilege lives. Grant an agent Agent Access to only the MCP servers its job needs, make one team a User on the model account it is allowed to call, and add an MCP Server Approver when a tool should require sign-off before it runs. No custom role creation is needed for any of it.

Tenant-level roles

Tenant-level roles apply across the whole tenant and are configured under Access, then Roles. They govern tenant-wide actions such as creating resources, managing users, and listing every resource of a type. TrueFoundry ships with two: Admin, which is full control and should stay limited to a handful of people, and Member, which by default has access to nothing and must be granted resource access explicitly. When those two are too broad or too narrow, you create a custom role.

‍

Roles can attach to teams as well as individual users, and a user's effective permissions are the union of their own role and every role inherited from their teams. For organizations that sync identity groups over SCIM, those groups come in as TrueFoundry teams and can be granted roles directly, so access follows the same source of truth your IdP already manages.

How Access Control Works for MCP Tools

The MCP Gateway separates three concerns that teams usually tangle together, and keeping them apart is what makes tool-level least privilege practical.

Layer

What it controls

Inbound authentication

How a caller (agent, developer, app) authenticates to the gateway, via a gateway token

Access control

Which users, teams, or agents can use which MCP servers and specific tools

Outbound authentication

How the gateway authenticates to the downstream MCP server

‍

Product screenshot, TrueFoundry docs: MCP Gateway auth and authz.

‍

The important part for agents is the middle layer. Access rules can narrow all the way down to individual tools within a server, so you can grant an agent the read-only ask_question tool of a database server while withholding the tool that writes to it. Because the gateway sits in front of every call, the same rule covers every caller of that tool, agents included, with nothing to reimplement per agent.

Enforcing Least-Privilege in Practice

Least privilege is less a feature and more a habit that the gateway makes easy to keep. A few patterns carry most of the value.

‍

• One identity per workload, scoped tight. Give each application its own virtual account and each agent its own agent identity, then grant each only the model accounts and MCP tools it actually uses. Shared, broadly scoped credentials are what make blast radius large.
• Scope agents to their function, not their driver's. A customer-support agent should reach the support tools and nothing near financial records or admin endpoints, even when the person running it has wider access. Agent-level grants make that separation real.
• Use approver roles for sensitive tools. The MCP Server Approver role puts a human in the loop before high-impact tools run, which is often safer than a hard allow or deny.
• Prefer teams over per-user grants. Assign roles to a team once and manage membership, so access stays legible as people and agents come and go.

‍

For authorization that depends on request context rather than a static role, the gateway supports policy-as-code guardrails using Cedar and OPA at the pre-tool hook. These let you express fine-grained rules, for example allowing a tool call only when request metadata marks it as a non-production environment. In production, applications authenticate with a scoped Virtual Account token rather than a personal one, and can tag each call with metadata the policies read:

‍

curl https://gateway.truefoundry.ai/api/llm/chat/completions \

  -H "Authorization: Bearer $VIRTUAL_ACCOUNT_TOKEN" \

  -H 'X-TFY-METADATA: {"environment":"production","team":"support"}' \

  -H "Content-Type: application/json" \

  -d '{ "model": "openai-main/gpt-4o", "messages": [ ... ] }'

‍

‍

::: CRO BANNER ::: Scope every agent to exactly what it needs. TrueFoundry enforces role-based access to models and MCP tools at the gateway, inside your own VPC. CTA: Book a demo → /book-demo :::::::::::::::::::

Why Enforce Agent Access at the Gateway

You could try to build these checks into each agent, but the reason not to is coverage. When access is enforced at the gateway, a new agent that calls an already-governed model or MCP server inherits its access rules automatically, with nothing to add to the agent's code. Agents built on LangGraph, CrewAI, AutoGen, or a custom loop all route through the same control plane and get the same policies.

‍

It also keeps access decisions where they can be audited. Every call carries the identity of the caller and the resource it reached, so you can answer "which agents can touch this tool" from one place instead of reading a dozen repos. Access control, agent identity, and guardrails then compose into one governed call path: identity says who is calling, access control says whether the call is allowed, and guardrails inspect what it contains. The gateway adds only a few milliseconds of overhead while doing it, so putting all three in the hot path does not slow agents down.

‍

The result is access control that behaves like infrastructure. It is applied uniformly, owned by the platform team, and enforced inside your own AWS, GCP, or Azure account, which is what makes SOC 2, HIPAA, and GDPR reviews tractable.

‍