# AgentFort Access: least privilege access for AI agents, decided call by call

> Least privilege access for AI agents means each agent can perform only the operations its job needs, within limits, on records it has reason to touch. AgentFort Access sits between agents and the services they call, over REST and MCP, and checks every call: the agent's identity, the exact operation, its arguments, the record it touches, who it acts for, and the budget.

Source: https://agentfort.net/platform/access · Updated 2026-10-28 · AgentFort

## 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](/agent-security/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.

```cedar
// 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](/agent-security/human-approval) and [spending limits](/agent-security/spending-limits) cover the design choices, and [How to stop an AI agent issuing a $4,500 refund](/blog/stop-ai-agent-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](/blog/keep-your-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](/platform/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](/platform/identity) supplies the verified agent and the person it acts for. Access decides the call. [AgentFort Data Protection](/platform/data-protection) inspects what moves in both directions. [AgentFort Isolation](/platform/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](/agent-security/) covers the wider picture.

## See Access in front of your own services

[Request a demo](/demo) to walk through Access against services like yours, or [apply as a design partner](/design-partners) to put it in front of the systems that move money or hold regulated data.

## 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.

## Sources

- [What is Cedar? (Cedar policy language documentation)](https://docs.cedarpolicy.com/)
- [External authorization filter (Envoy documentation)](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter)
- [OpenAPI Specification](https://spec.openapis.org/oas/latest.html)