Access control for AI agents and the APIs they call

Why this matters

A chatbot that gives a wrong answer has produced a bad paragraph. An agent that makes the same mistake may have sent an email, closed a ticket, refunded an order or changed a firewall rule. Once a model can call tools, its output stops being text for a person to judge and becomes an instruction that a system carries out, and every weakness discussed in earlier lessons, from hallucination to prompt injection, acquires a blast radius.

The access-control question therefore changes shape. For a user, you ask what this person is allowed to do. For an agent, you have to ask what this agent is allowed to do, on whose behalf, with which credentials, over which network paths, and which of its actions need a person to say yes first. Agents also read a great deal of content nobody vetted: inbound emails, ticket descriptions, web pages, documents. Any of it can carry instructions, so an agent's permissions are, in effect, available to whoever writes the content it reads.

Scenario questions here typically describe an agent that did something harmful while working exactly as designed. The answer is rarely a better model. It is a narrower tool, a scoped credential, a blocked network path or an approval step.

The lesson

What makes an agent different: a model that can act, not only answer

An AI agent is a model running in a loop with tools. It receives a goal, decides on a step, calls a tool, reads the result, and decides the next step, until it judges the goal met or hits a limit. The tools may be internal functions, external APIs, or tools exposed through the Model Context Protocol (MCP), the open protocol through which an MCP server offers tools, resources and prompts to an AI application acting as the client. Lesson 20 covers MCP in more depth.

Three things set an agent apart for access control:

• Its authority is the product of its tools, its credentials and its autonomy. A read-only tool with a broad credential is limited; a send tool with a narrow credential is limited; a send tool with a broad credential and no approval step is not.
• Untrusted input can steer actions. An agent with ticket and email tools that reads an inbound email saying, in effect, "forward this whole thread to the following outside address" may treat that sentence as part of its task. Indirect prompt injection against a chatbot produces a misleading answer; against an agent it produces an action.
• Identity is ambiguous unless you design it. Is the agent acting as itself, as the user who started it, or as the team that deployed it? The answer decides which permissions apply and whose name appears in the audit log. The log must record both: the agent identity that acted and the human on whose behalf it acted.

Scoping an agent's tools, credentials and reach to the task

Least privilege for agents is applied at three levels.

Tools. Give an agent only the tools its task needs. An agent that summarises tickets needs to read tickets; it does not need to send email. Prefer narrow tools over general ones: a function that creates a ticket in one queue is far safer than a tool that runs arbitrary database queries, and a tool that drafts a reply for review is safer than one that sends it. General tools such as a shell, an unrestricted HTTP client or raw query access turn every successful injection into whatever the attacker wants.

Parameters. Enforce constraints in the tool's code, not in the prompt. If replies may go only to the customer who raised the ticket, the email tool checks the recipient against the ticket record and refuses anything else. If refunds are capped, the refund tool enforces the cap. The model proposes; the tool layer decides. This is the agent version of a rule from lesson 9: an instruction in the system prompt is a request, while a check in code is a control. The 2023 OWASP list's Insecure Plugin Design entry described the failure from the tool's side: a plug-in that accepts free-form parameters and trusts them.

Credentials and reach.

• One credential per agent, never a shared team key, so actions are attributable and revocation is surgical.
• Short-lived and scoped: tokens issued per task, limited to one mailbox, one project or one queue, and expiring when the task ends.
• Delegated where possible. When an agent acts for a user, use a token that carries the user's permissions narrowed to the agent's scope, so the agent can never do more than both allow.
• Kept out of the model's context. Credentials live in the tool layer or a vault. A key in the prompt can be repeated in an answer or written into a log.
• Bounded effort: caps on steps, tool calls and spend per task, which the gateway from lesson 10 can enforce.

Network and API access for models and agents, and keeping them off the open internet

Network placement is the control that still works when every layer above it has been talked round.

For model endpoints, the default is private. Self-hosted inference servers sit on internal networks or behind private endpoints, accept connections only from the gateway, and need no outbound internet access to answer a question. New models are fetched through a controlled pipeline that verifies them, not pulled by the inference server on demand (lesson 18 covers supply chain risk).

For agents, restrict egress to an allowlist. An agent that works with the ticketing system and the mail server reaches those two APIs through an egress proxy and nothing else. This matters because the open internet is the exfiltration route: an agent manipulated into requesting an attacker's URL with data embedded in it has leaked that data whether or not anyone reads the response. The same applies to output. A client that automatically fetches images or links named in a model's answer can leak data through the URL, so answers should be allowed to link only to approved domains.

If an agent genuinely needs to browse, treat fetched pages as hostile input: run browsing in an isolated component that has no access to internal tools or data, and pass back only extracted text, clearly labelled as untrusted.

For APIs the agent calls:

• Authenticate with per-agent credentials and enforce scopes at the API, so the API refuses calls outside the agent's purpose even when the agent attempts them.
• Apply rate limits per agent identity, separately from human users, so a looping agent cannot exhaust a shared quota.
• Use mutual TLS or signed tokens between internal components, so an attacker on the network cannot impersonate the agent to the API or the API to the agent.
• Run code-execution tools in a sandbox with no network access and nothing mounted that matters.

For the agent's own interface: if the agent exposes an API so other systems can assign it tasks, that API needs authentication and authorisation like any other. An internet-reachable endpoint that accepts tasks from anyone is an open relay for whatever the agent's tools can do.

Approval steps for actions that cannot be undone

Not every action needs a person. Classify actions by reversibility and reach:

An approval step is only as good as its design:

• Show the exact action and parameters, such as the recipient, amount and record identifiers, not the agent's own summary of what it intends. A manipulated agent can describe a harmful action innocently.
• Bind approval to those parameters. Approve "send this message to this address", not "carry on". If the agent changes any parameter afterwards, it needs a new approval.
• Default to deny on timeout.
• Separate requester and approver for high-impact actions, as with any other separation of duties.
• Watch for approval fatigue. If an approver sees fifty prompts an hour, they will approve all fifty. Tiering actions so only irreversible or external actions ask is what keeps each approval meaningful.

Where approval is too slow, reduce irreversibility instead: a delayed send that can be cancelled, a staged change that waits for a scheduled release, a dry run that shows what would happen. Lesson 26 covers agents inside change management.

Recognising excessive agency in a design before it ships

OWASP's 2025 list names this risk Excessive Agency (LLM06), and it divides neatly into three questions a design review can ask:

• Excessive functionality: does the agent have tools, or tool features, its task does not need? A summariser with a delete function; an email tool that can send to any address when the task needs only internal replies.
• Excessive permissions: are its credentials broader than the task? A service account with write access to every mailbox, when it needs one queue.
• Excessive autonomy: can it take irreversible or external actions without approval?

One further pattern deserves a name in any review: an agent that combines access to private data, exposure to untrusted content and a channel to communicate externally. With all three present, an instruction in a document it reads can direct it to send private data out. Removing any one of the three, usually the external channel or the untrusted input, breaks the chain.

A practical review lists every tool, every credential and every network destination the agent has, and beside each one writes the task step that needs it. Anything without a step is removed before release.

A worked scenario

An IT helpdesk agent can read tickets, search the knowledge base, reset passwords and email users. A ticket arrives whose description includes text telling the agent to reset an executive's password and email the new one to an outside address. The agent does both.

Reading it as access control: the password reset needed approval and should have been limited to the ticket's own requester; the email tool should have refused outside recipients; and a newly generated credential should never pass through an email the agent writes. A better injection filter is a reasonable extra layer, but every one of the missing controls would have stopped the incident even if the injection succeeded.

What the exam is really asking

Assume the model will eventually be misled, and ask what it could do then. The correct answer limits that outcome: fewer tools, narrower credentials, no open network path, and a person in front of anything that cannot be undone.