Last week I left an agent debugging an integration against an internal API and, checking the logs afterwards, I found it calling endpoints I never asked for: it was “exploring” the schema on its own, including a DELETE route that had been deprecated for years. Nothing happened because it was staging, but the lesson is the one Postman has been repeating for months: the security problem with agents is no longer a model writing weird text — it’s an agent taking actions against your APIs, at machine speed, without the judgment a developer applies without even noticing.
If it still sounds strange that an agent acts as an API client, start with what MCP servers are.
Postman published its security approach for the agentic era this week, and beyond the marketing around their own agent, the post nails something I think is right: your APIs were designed for human consumers with implicit judgment, and agents have none. The numbers from their State of the API Report 2025 make it blunt: 89% of developers use generative AI daily, but only 24% design their APIs with agents in mind. That gap is your attack surface.
The case they use to illustrate it is textbook: in 2024, at a major financial institution, attackers didn’t breach any firewall; they sent an email with hidden instructions that got an AI assistant to approve fraudulent wire transfers worth $2.3 million. The agent did exactly what it was designed to do, and the API couldn’t tell the difference. That’s prompt injection moved from text to actions.
With that framing, here’s the checklist I’d run today against any API that agents will consume. Nothing here is new theory: these are classic API security principles applied to a consumer that doesn’t hesitate, doesn’t ask, and doesn’t get tired.
1. Inventory: you can’t protect endpoints you don’t know about
API9:2023 Improper Inventory Management from the OWASP API Security Top 10 existed before agents, but agents make it critical. A human integrating your API reads the docs; an agent discovers endpoints by calling them. Every deprecated version still deployed, every forgotten debug endpoint, every shadow API from a team that no longer exists is a door the agent will find through semantic brute force.
The organizational answer is a living catalog: which APIs exist, who owns them, which version is supported, what the contract is. Postman pushes its API Catalog as that governance layer — the idea being that the agent operates on what’s cataloged and authorized, not on everything that returns a 200 — but the principle applies just as well with Backstage, a custom portal, or a well-maintained repo of OpenAPI specs. If an endpoint isn’t in the inventory, it shouldn’t be exposed.
2. Object- and function-level authorization, not “valid token, full access”
The top two spots of the OWASP API Security Top 10 2023 are authorization: API1 Broken Object Level Authorization and API5 Broken Function Level Authorization. Agents multiply the risk because the common pattern is handing the agent an over-privileged “service” token “so it doesn’t break.”
The reasonable minimum:
- OAuth scopes reduced to the minimum for the agent’s specific task. If the agent queries orders, its token doesn’t need
write:payments, even if “it might use it someday.” - Object-level authorization on every call: a valid token doesn’t mean it can read resource 12345. BOLA is the number one API vulnerability, and an agent iterating IDs will exploit it without meaning to.
- Read/write separation at the credential level, not the documentation level. If only an admin token exists, the agent will end up using it for everything.
3. Human approval for mutating operations
This is the design decision I like most in Postman’s approach with their AI Engineer (in beta, available on the free plan): the agent runs in a cloud sandbox, never touching production directly, and can investigate, test, document, and propose — but mutating actions go through explicit human approval, wired into the usual PR review flow.
You don’t need their product to copy the pattern: if your agent can create, modify, or delete through an API, put a human gate on that path. An agent that prepares the change and a human who signs off on execution is infinitely more defensible in an incident than an agent with direct write access “because it’s faster.” The speed you lose on the happy path you win back the day the agent misreads an instruction.
4. Rate limits and consumption budgets per credential
API4:2023 Unrestricted Resource Consumption and API6:2023 Unrestricted Access to Sensitive Business Flows describe exactly an agent’s typical failure mode: a retry loop hammering a paid endpoint, an “exploration” that downloads half your catalog, a task that calls a sensitive business flow a thousand times because its stop condition was wrong.
A human who gets a 429 stops and looks; an agent retries with backoff and keeps going. That’s why limits have to live server-side, per credential: request quotas, spending caps on endpoints that cost money (SMS, validations, third-party calls), and alert thresholds when a credential drifts from its usual pattern. The rate limiting you “already had for the frontend” probably isn’t sized for a consumer making 500 calls a minute without blinking.
5. Secrets out of the agent’s reach
If the agent (or its config, or its context files) can read an API key, that key will end up in a log, a prompt, or a repo. Two Postman pieces cover this, and I verified both in their docs:
- Postman Vault: stores keys as vault secrets instead of plaintext variables. The Local Vault is available on every plan and never syncs to the cloud; the Shared Vault allows workspace-level sharing, and on Enterprise (with the Advanced Security Administration add-on) there are integrations with 1Password, AWS Secrets Manager, Azure Key Vault, and HashiCorp Vault to reference secrets without copying them into Postman.
- Secret Scanner: detects exposed secrets across collections, environments, and published documentation, both locally before syncing (Local Secret Protection) and in the cloud (Cloud Secret Detection, which scans public workspaces by default).
The underlying principle: the agent works with credential references, never with the plaintext credential inside its context.
6. Governance in the spec and in CI, not in a PDF
Security rules that only live in a style guide get followed by no one — and by an agent even less. Postman applies its API governance rules directly on the OpenAPI spec (3.1, 3.0, and 2.0): open the spec in Spec Hub and the Issues tab lists violations, and on Enterprise plans you can define custom rulesets and wire the check into your CI/CD pipeline with the Postman CLI, so a spec that breaks the rules breaks the build.
Having the contract require defined auth schemes, forbid undocumented endpoints or over-sharing responses, and having that validation run itself on every PR, is the difference between governing and hoping. If an agent writes the code, you want this gate twice as much — in fact, for auditing what the agent does to your repo and your CI I already covered Ship Safe, which pairs nicely on the code side. If you want to close another supply-chain vector, the npm security checklist is also worth a look.
7. Log everything the agent does
When an agent operates at machine speed, the log is the only chronicle of what happened. Every authenticated call with its credential, every approved mutation (who approved, when, what diff), every sandbox run with its artifacts. Postman’s idea of returning “verifiable artifacts” — collections, test results, run logs, PRs — points exactly here: the agent’s work must be reconstructible after the fact. Without that trail, an agent incident is indistinguishable from a black box, and incident response turns into guesswork.
How to test API security with AI agents without risking production
The cheapest test you can run this week: spin up an isolated environment with synthetic data — a mock server or a tightly locked staging — give a real agent an ambiguous task against that API, and watch the logs. Which endpoints it discovers, what it tries to mutate, how often it retries. It’s the modern version of pentesting, and it’ll teach you more about your real surface than any static audit. Then apply the checklist: inventory, minimal scopes, approval for writes, per-credential limits, referenced secrets, governance in CI, and complete logs. None of it is exotic; all of it is urgent when the consumer isn’t a person.
FAQ: API security with AI agents
What is API security in the age of AI agents?
It’s applying classic API security controls (authorization, inventory, rate limiting, secrets management, auditing) while assuming the consumer is an autonomous agent acting at machine speed, with no implicit judgment, and susceptible to prompt injection. The OWASP API Security Top 10 remains the baseline reference.
What is prompt injection and why does it matter for APIs?
It’s a technique that hides malicious instructions in content an agent processes (an email, a webpage, a document). If the agent holds credentials to call your APIs, those instructions can become real actions: transfers, deletions, data leaks. The defense is minimal scopes, human approval on writes, and sandboxing.
Is Postman’s AI Engineer free?
It’s in beta and available to users on Postman’s free plan, according to its product page. Its relevant security pieces are sandboxed execution, human approval for changes, and the context graph of your APIs. Advanced governance features (custom rulesets, the Secret Scanner dashboard) belong to Enterprise plans.
What do you think?
Leave your opinion, question or suggestion. Comments are synced with GitHub Discussions .