What least privilege access for AI agents means here
Discover found the agents and Identity proved who each one is. The next question is what each agent may do, and to which records. Today most services hand every agent one shared key, and that key can do everything.
Least privilege access for AI agents means an agent can perform only the operations its job needs, with arguments inside set limits, on records it has reason to touch. AgentFort Access is an authorization layer that sits between agents and the services they call, over REST and MCP. Ordinary access control asks "can this agent reach this system?" Access checks the call itself. Your agent is allowed to call your billing API; AgentFort decides whether this $4,500 refund should happen. The vendor-neutral guide is AI agent authorization.
Registering a service
An administrator registers each service from its OpenAPI definition, or from its MCP server. AgentFort suggests how risky each operation is and which fields are sensitive, and the service owner approves. In the recorded demo at Northwind, a simulated company, Maria owns the CRM. She closed customer deletion entirely and approved exactly what she reviewed. The billing API and the knowledge base's MCP server were registered the same way.
Grants with conditions on the arguments and the record
Access is granted per agent and per operation, with conditions on the arguments and on the record itself. Anything not granted is denied, and a forbid always wins. Owners describe rules in plain English. AgentFort compiles them into Cedar policies the owner can read, test against examples and replay against past requests before publishing. Administrators set ceilings, owners delegate within them, and grants expire.
// Illustrative only: Support Triage may read cases in the support queue
permit (
principal == Agent::"support-triage",
action == Action::"cases.read",
resource
) when { resource.queue == "support" };
// Illustrative only: no agent may delete customer data
forbid (principal, action == Action::"customers.delete", resource);
When Support Triage asked for a sales case, AgentFort read the record itself, saw the queue and refused.
What the agent sees and what the service sees
AgentFort calls the service with its own credential, scoped to that one operation. Agents never hold the service key. In the demo, the CRM only ever saw a token that could read customers; if it leaked, it could not change anything. AgentFort also hides fields the agent may not see. Looking up a customer, Support Triage got the email and phone, while the social security number and birth date stayed hidden.
Over MCP, an agent sees only the tools it may use. Claude, acting for Priya, connected and saw just the 2 tools it was granted. It could update Priya's cases, but not Lena's.
Approvals and budgets
Some calls should run, some should wait for a person, and some should never run. Limits apply per argument and per period, and approvals go to a named approver who sees the exact call.
| Refund request at Northwind | Outcome |
|---|---|
| $40 | Runs on its own |
| $450 | Held for Dana in Finance; runs once after she approves; asking again needs her again |
| $4,500 | Blocked by the limit of $2,000 per invoice per week |
| A refund on another customer's invoice | Denied after AgentFort reads the invoice |
The guides on human approval and spending limits cover the design choices, and How to stop an AI agent issuing a $4,500 refund walks through this example.
Tightening access over time
AgentFort compares what each grant allows with what agents actually do. It suggests removing access that is never used and tightening limits, and it replays past calls to show exactly what would change. When a service adds a new tool, it stays closed until its owner approves it.
Working with the gateway you already run
AgentFort Access doesn't replace your API gateway. AgentFort works with it in one of 3 ways:
| Mode | Where AgentFort sits | What you get |
|---|---|---|
| Behind your gateway | Behind any gateway, such as Kong, Apigee or AWS API Gateway, as the last hop before the service | Full coverage |
| Inside an Envoy-based gateway | In Envoy or Istio, through the ext_authz filter | Decisions, approvals, budgets, record checks and receipts; no output masking |
| Beside your gateway | Next to it | Discover and Identity only |
Envoy's ext_authz filter calls an external service to decide whether each HTTP request is authorized, which is how the second mode plugs in. Keep your API gateway explains where these decisions belong.
What Access doesn't do, and what you still need
Access decides what an agent may do. It doesn't look inside content for secrets or hidden instructions; AgentFort Data Protection does, and it stops bulk exfiltration even when Access allows sending email. Access also governs only the calls that pass through it.
- Route agent calls to services through AgentFort, and close direct paths at the network.
- Take service credentials away from agents.
- Name an owner for every registered service.
- Choose approvers who are not the people the agents act for.
How Access connects to the other controls
AgentFort Identity supplies the verified agent and the person it acts for. Access decides the call. AgentFort Data Protection inspects what moves in both directions. AgentFort Isolation gives a sandboxed agent one way out, through a broker that adds credentials the sandbox never sees. Every decision leaves a receipt in Visibility. The AI agent security guide covers the wider picture.
See Access in front of your own services
Request a demo to walk through Access against services like yours, or apply as a design partner to put it in front of the systems that move money or hold regulated data.
Video transcript
AgentFort Discover found the agents, and AgentFort Identity proved who each one is. Now the question is what each agent may do, and to which records. Today, most services hand every agent one shared key, and that key can do everything. AgentFort Access sits between agents and the services they call. Every call is checked: the agent's identity, the exact operation, its arguments, and the record it touches. Then AgentFort calls the service with its own credential, scoped to that one operation, and hides what the agent may not see.
It works behind the AgentFort gateway you already run, or as a front door for agents, over REST and MCP. First, an administrator registers the CRM from its OpenAPI definition. AgentFort suggests how risky each operation is, and which fields are sensitive. Maria owns the CRM. She closes customer deletion entirely, and approves exactly what she reviewed. The billing API, and the knowledge base's MCP server, are registered the same way.
Access is granted per agent and per operation, with conditions on the arguments and on the record itself. Anything not granted is denied, and a forbid always wins. Support Triage may read only support-queue cases. Personal assistants may touch only their own person's cases. And no agent may export or delete customer data. Support Triage reads a support case. When it asks for a sales case, AgentFort reads the record itself, sees the queue, and refuses.
Looking up a customer, it gets the email and phone. The social security number and birth date stay hidden. The CRM only ever sees a token that can read customers. If it leaked, it could not change anything. Claude, acting for Priya, connects over MCP, and sees just the two tools it may use. It can update Priya's cases, but not Lena's. The invoice reconciler refunds forty dollars on its own. Four hundred and fifty dollars needs Dana, from finance.
Dana sees the exact call, and approves it. It runs once. Asking again needs her again. Over time, AgentFort compares what each grant allows with what agents actually do. It suggests removing what is never used, and tightening limits, and replays past calls to show exactly what would change. And when a service adds a new tool, it stays closed until its owner approves it. AgentFort Access. Every agent gets exactly the access its job needs, and nothing more.
Frequently asked questions
What happens if the AgentFort control plane is unreachable?
AgentFort fails closed. If the gateway can't reach the control plane, it keeps enforcing the last signed rules for a short lease, 60 seconds by default and configurable. When the lease runs out, it refuses every call until the control plane is back. Agents never fall back to unchecked access, so an outage stops agent actions rather than letting them through.
How much latency does AgentFort Access add to agent calls?
In our lab, AgentFort Access added about 1 millisecond at the 95th percentile at 100 requests per second. That is a lab measurement, not a guarantee for every environment. Your services, network and policies will affect what you see, so measure it against your own services before you rely on it.
Can the person an AI agent acts for approve that agent's request?
Not with AgentFort. The person an agent acts for can't approve that agent's request: the agent is asking on their behalf, and the person asking shouldn't approve their own request. Approvals go to a named approver instead, such as Finance for a large refund. The approver sees the exact call, it runs once, and asking again needs a new approval.