How to Give AI Agents Access to APIs Without Giving Them Too Much Power

Wiring an agent up to GitHub, Stripe, or an internal API usually starts the same way: generate one token, grant it whatever scopes look like they'll cover everything the agent might eventually need, and drop it in an environment variable. It works immediately, which is exactly the problem. An agent built to triage issues and a token that can also delete the repository now live in the same variable, and the only thing standing between "labeled a bug" and "deleted the codebase" is whatever the model happens to decide to do next.

That gap between what a token can do and what the agent's actual job needs it to do is the real subject of this article. Not identity theory, that's covered in full in AI Agent Identity, and not the general threat surface, covered in AI Agent Security. This is the practical, hands-on version: how to actually shape an agent's access to a real API so the blast radius of a mistake, a bug, or a successful prompt injection is small by construction, not by hoping the model behaves.

The Architecture

The Default Failure Mode: One Token, Every Scope

A team building a GitHub issue-triage agent needs it to read open issues, label the ones that look like duplicates, and comment with a suggested owner. That's three narrow, read-and-reversible-write capabilities. The fastest path to a working prototype is a classic personal access token with the repo scope, because repo covers all of that and nobody has to think about it again.

Start From the Task, Not From What the API Offers

The least-privilege principle itself is covered in full in AI Agent Identity: scope to the task, not the role. Applied concretely to a real API, that means picking the narrowest credential type the provider actually offers, not the most convenient one.

GitHub's own fine-grained personal access tokens make this a real choice instead of a wish:

Classic PAT, scope: repo
  -> read/write across every repo the owner can reach
  -> branch and settings admin, org-level in some configurations
 
Fine-grained PAT, scoped explicitly
  Repository access:  only "acme/support-triage"
  Permissions:
    Issues:            Read and write
    Pull requests:      No access
    Contents:           Read-only
    Administration:      No access

One Tool Per Capability, Never One Tool That Calls Any Endpoint

This is the same lesson as Build an AI Agent That Can Safely Execute PowerShell Commands, applied to any REST API instead of a shell: the single most important decision isn't the token's scope, it's whether the model is ever given a free-text parameter that reaches the API directly.

# WRONG: the model constructs the request
@tool()
def call_github_api(method: str, path: str, body: dict | None = None) -> dict:
    """Call any GitHub API endpoint."""
    ...  # scoping the token narrowly doesn't save you here

# RIGHT: the model picks a name, the code owns the request shape
import requests
 
GITHUB_API = "https://api.github.com"
 
def list_open_issues(repo: str) -> list[dict]:
    resp = requests.get(
        f"{GITHUB_API}/repos/{repo}/issues",
        headers=_auth_headers("read"),
        params={"state": "open"},
        timeout=10,
    )
    resp.raise_for_status()
    return resp.json()
 
def add_label(repo: str, issue_number: int, label: str) -> dict:
    resp = requests.post(
        f"{GITHUB_API}/repos/{repo}/issues/{issue_number}/labels",
        headers=_auth_headers("write"),
        json={"labels": [label]},
        timeout=10,
    )
    resp.raise_for_status()
    return resp.json()

Tier Every Tool by Blast Radius

Not every capability in the tool layer deserves the same amount of friction. Once each capability is its own named function, tiering them is just a matter of being honest about what each one can actually do if it's called wrong.

TOOL_TIERS = {
    "list_open_issues": 1,
    "get_issue": 1,
    "add_label": 2,
    "post_comment": 2,
    "close_issue": 3,
}
 
def dispatch(tool_name: str, **kwargs) -> dict:
    tier = TOOL_TIERS.get(tool_name)
    if tier is None:
        return {"ok": False, "error": f"Unknown tool '{tool_name}'"}
 
    if tier == 3 and not human_approved(tool_name, kwargs):
        return {"ok": False, "status": "pending_approval", "tool": tool_name, "args": kwargs}
 
    result = TOOL_FUNCTIONS[tool_name](**kwargs)
    log_call(tool_name, kwargs, tier)
    return {"ok": True, "result": result}

Rate Limits and Spend Caps Are Part of the Permission Model

A correctly scoped, correctly tiered tool can still do real damage at volume. add_label touching one issue is fine. add_label called two thousand times in a runaway loop, because a bug or an injected instruction kept the agent retrying, is a mess regardless of how narrow the token was.

from collections import deque
import time
 
class RateLimiter:
    def __init__(self, max_calls: int, window_seconds: int):
        self.max_calls = max_calls
        self.window_seconds = window_seconds
        self.calls: deque[float] = deque()
 
    def allow(self) -> bool:
        now = time.monotonic()
        while self.calls and now - self.calls[0] > self.window_seconds:
            self.calls.popleft()
        if len(self.calls) >= self.max_calls:
            return False
        self.calls.append(now)
        return True
 
tier_2_limiter = RateLimiter(max_calls=20, window_seconds=60)
 
def dispatch(tool_name: str, **kwargs) -> dict:
    tier = TOOL_TIERS.get(tool_name)
    if tier == 2 and not tier_2_limiter.allow():
        return {"ok": False, "error": "Tier 2 rate limit reached for this run"}
    # ...tier 3 check and execution as before

Circuit Breakers: Stop the Run, Don't Keep Retrying Into It

A rate limit caps volume. A circuit breaker responds to a pattern that looks wrong and stops the run before the cap is even reached.

def check_circuit(recent_results: list[bool], threshold: float = 0.3) -> bool:
    if len(recent_results) < 5:
        return True  # not enough data yet, allow
    failure_rate = recent_results.count(False) / len(recent_results)
    return failure_rate < threshold

A Worked Trace

The issue-triage agent is asked to "look at open issues in acme/support-triage and label the ones that look like duplicates."

Where This Fits With MCP

If the API is exposed to the agent through an MCP server rather than direct HTTP calls, the same tiering belongs at the server boundary, not just in application code. MCP Explained and Build Your First MCP Server cover the protocol itself; the tiering model here maps directly onto it, one MCP tool per capability, exactly as narrow as the equivalent function above, with the tier check and rate limiter living in the server's tool handler rather than a bespoke dispatch function.

When a Broader Token Might Actually Be Fine

The Bottom Line

The convenient way to connect an agent to an API is one token, every scope it might conceivably need, and a generic function that can call anything that token allows. Every piece of that convenience is also exactly where the damage happens when the agent gets something wrong, whether that's a bug in its reasoning or a successful prompt injection. The fix isn't a smarter agent or a more careful prompt. It's a tool layer where each capability is its own named function, a credential scoped to only what that function needs, a tier that decides whether a human has to look at it first, and a rate limit and circuit breaker that catch volume before it becomes a real incident.

A token that can do everything is not a feature you're saving for later. It's the blast radius of whatever goes wrong first, sitting there fully formed before the agent has done anything at all.