The AI Agent Security Checklist: Inventory, Least Privilege, Kill Switch, Secret Rotation, Spend Limits

Gate 1 — Inventory every agent and every tool it can call

Most teams discover they have agents in production the way they used to discover shadow SaaS: on the invoice. Build a live inventory now, before the first incident.

• Agent identity: name, owner team, source repo, LLM provider and model, framework (LangGraph, LlamaIndex, OpenAI Agents SDK, Anthropic MCP host, bespoke).
• Trigger surface: inbound webhook, scheduled job, Slack command, user prompt via UI, MCP tool call.
• Tool catalogue: every tool/function the agent can invoke. Name, parameters, side-effects (read-only / writes / spends money).
• Data in scope: which tables, buckets, Slack channels, SaaS tenants and secrets the agent's tools can touch.
• Egress identity: the IAM principal or service-account the agent authenticates as; the API keys it holds; the models it is permitted to call.

Compliance mapping: ISO/IEC 42001 clause 6.1.3 (identification of AI system components) · NIST AI RMF Govern 1.6 and Map 1.1 · EN 18286 §5.2 (AI system inventory).

Gate 2 — Least privilege, scoped to the smallest unit of work

Agents inherit the identity they run under, not the identity of the human who kicked them off. The default of "same role as the deploying service" is wrong. Treat each agent as its own workload with its own scoped identity.

• One agent, one IAM principal / service account, one set of permissions. Do not share.
• Grant permissions at the tool level: if a tool only reads invoices, the identity has only Read on Invoices.
• No ambient cloud credentials on the agent host. No *.amazonaws.com/* wildcard egress policies.
• For LLM provider access: project-scoped keys, one project per agent, hard-separate production from eval/dev.
• For MCP servers: tool-level allowlists per client identity. Not "the agent can call any tool on this MCP server" — "this agent can call these three tools, at most N times per minute."
• Human-in-the-loop for actions that cross a value or sensitivity threshold: sending external email, pushing to a repo default branch, posting in a public Slack channel, writing to a shared drive.

Compliance mapping: ISO/IEC 42001 clause 8.3 (operation of AI systems) and Annex A.8.2 · NIST AI RMF Govern 1.2, Manage 2.1, Manage 4.2 · EN 18286 §6.4 (access control for AI components).

Gate 3 — Kill switch: one operator, under 60 seconds

Agents go wrong at machine speed. You need a single command that stops them at the identity layer, not an ask-the-vendor ticket.

• Per-agent disable flag: a config key that the agent process checks before every tool call, backed by a durable store. Default state should be checked at or below 5 seconds.
• Provider-side kill: pre-written runbook (and better, a one-line script) that rotates / revokes the agent's LLM provider key, cloud identity, and MCP client credentials in parallel.
• Egress kill: a WAF or egress-proxy rule you can enable to drop all traffic from the agent subnet to api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, and your MCP endpoints.
• Rehearse quarterly. Time the drill. Write the time in a shared doc. If it takes longer than 60 seconds, the gate is not met.

Compliance mapping: ISO/IEC 42001 Annex A.9.3 (incident response for AI systems) · NIST AI RMF Manage 2.3, Manage 4.1 · EN 18286 §8.3 (system-level safe-state controls).

Gate 4 — Secret rotation: scheduled and on-demand

The GitBook and WorkOS incidents both ended in a rotate-everything drill. Make rotation boring so that when it is urgent it is also fast.

• Rotation schedule for every agent credential: LLM provider keys, cloud identities, OAuth refresh tokens, MCP client secrets, webhook signing keys. Hard-cap maximum age (90 days is a reasonable ceiling; shorter for high-value credentials).
• Single-command on-demand rotation per credential class. A playbook that takes 20 minutes to find the right page in the vendor console is not rotation — it is hope.
• No credentials in source. Secrets scanning in CI gates merges; secrets in .env files, Terraform state, container images, and Helm values are a release blocker.
• Short-lived where possible. Workload identity federation (GitHub-to-AWS/GCP/Azure, GKE/EKS/AKS service accounts) over long-lived keys. OAuth with scope-minimised grants over PATs.
• Rotation on vendor-incident signal. Build the muscle to rotate the whole agent fleet when a SaaS dependency discloses a breach — not weeks later when the ticket comes due.

Compliance mapping: ISO/IEC 42001 Annex A.8.3 · NIST AI RMF Manage 2.2 · EN 18286 §6.4.3 (credential lifecycle management).

Gate 5 — Spend limits: hard caps at the provider

LLMjacking turns a stolen key into a $1M bill in hours. Cap at the provider, not just the gateway — the gateway is what the attacker first bypasses.

• Hard budget at each LLM provider: OpenAI project limits, Anthropic workspace caps, Google Vertex budgets, AWS Bedrock cost controls, Azure OpenAI quota.
• Alert thresholds at 25%, 50%, 80% of monthly cap. Page on-call at 80%, not at 100%.
• Per-agent and per-team quotas inside your gateway (LiteLLM, PortKey, bespoke). Not a nice-to-have — a hard quota that returns a 429 instead of a $900 completion.
• Anomaly detection on request-rate and token-shape: sustained >10× baseline RPS from any agent identity is an incident until proven otherwise.
• Separate spending identities from scraping / batch / eval workloads. One agent that goes rogue should not take the whole AI budget with it.

Compliance mapping: ISO/IEC 42001 clause 8.4 (resource management) · NIST AI RMF Manage 3.1, Measure 2.6 · EN 18286 §7.2 (operational guardrails).

A note on the three frameworks

• ISO/IEC 42001:2023 is the AI Management System certification — Annex A controls are where your auditor will look for inventory, access control, rotation and incident response.
• NIST AI RMF 1.0 is the functional reference — Govern / Map / Measure / Manage — and maps most cleanly to how security teams already think. Each gate above references the specific subfunction.
• EN 18286 is the new European harmonised standard for AI system safety under the EU AI Act. If you ship to EU customers or operate a high-risk AI system in-region, EN 18286 §5–§8 are the clauses that your conformity assessment body will test.

All three overlap more than they conflict. The practical move is to pick one as your source-of-truth control library (most teams pick NIST AI RMF for engineering clarity or ISO/IEC 42001 for certification) and crosswalk once. The checklist above is the common denominator.

The quick audit question

Ask your lead engineer on any agent product: "If I need to stop every instance of this agent and rotate every credential it holds, how long does it take and who runs the command?" If the answer is longer than five minutes or more than one person, the gate is not met. Fix the gate before you ship the next feature.

How TigerGate helps

• AI Security Posture Management (AI-SPM) enumerates every agent, model, API key, gateway and MCP server across your repos, images, clouds and runtime — the inventory gate turned into a live source of truth.
• Identity Security surfaces over-privileged agent identities and the IAM blast radius of each one, so least-privilege is a dashboard, not a quarterly guess.
• Secrets scanning flags LLM provider keys, MCP client secrets and OAuth tokens leaking into source, CI, or container images — the pre-condition for rotation to actually mean something.
• eBPF runtime detection watches for anomalous outbound to AI providers and tool-call volumes outside baseline — your kill-switch trigger, not a monthly report.
• Compliance evidence maps every control above to ISO/IEC 42001, NIST AI RMF and EN 18286 clauses, with the evidence pre-staged for audit.