Non-human users are not new: service accounts, API keys, certificates, cron jobs, CI/CD systems, and workloads have always called internal APIs. AI agents and MCP servers make the problem more visible because machines can now choose tools and sequences dynamically. The core security requirement remains the same: each caller needs a stable identity, minimum authority, clear ownership, short credential lifetime, and observable behavior.
Separate non-human identities by purpose
A single 'service account' category hides very different risks. Inventory identities by how they are created, how long they live, who owns them, and whether they can act autonomously.
| Identity type | Typical use | Primary risk |
|---|---|---|
| Workload identity | Service-to-service calls | Over-broad role or network trust |
| CI/CD identity | Build, deploy, infrastructure changes | High privilege and supply-chain compromise |
| Automation account | Scheduled jobs and integrations | Long-lived secrets and forgotten ownership |
| AI agent identity | Dynamic tool/API workflows | Delegated authority and unpredictable sequences |
| MCP server identity | Broker access to tools/resources | Credential concentration and confused-deputy risk |
Inventory ownership before credentials
Every machine identity should have a business and technical owner, purpose, environment, credential mechanism, allowed APIs, and lifecycle. Orphaned credentials are dangerous because teams hesitate to revoke them when nobody knows what will break.
- Record owner and application/service dependency.
- Distinguish human-delegated actions from independent workload actions.
- Map every identity to allowed services, functions, and data classes.
- Track where credentials are stored and rotated.
- Set expiration or recertification for identities with no natural lifecycle.
Prefer short-lived workload identity over static secrets
Static API keys and long-lived client secrets are easy to copy and hard to attribute. Where platforms support it, prefer workload identity, federation, signed short-lived tokens, managed identities, or mTLS certificates with automated rotation.
A short credential lifetime does not fix excessive permissions, but it reduces how long a stolen credential remains useful and makes revocation operationally easier.
Preserve the difference between machine authority and user delegation
An AI agent may act for a user, a department, or itself as a workload. Those are different authorization contexts. Avoid collapsing them into one powerful backend service identity.
User-delegated
The agent should carry the user’s permitted scope where practical.
Workload-owned
The service acts for its own operational purpose, not as a user.
Elevated action
Administrative or destructive tools may require separate approval or step-up policy.
Cross-system
Downstream APIs should know the actual client/audience, not accept a token minted for another service.
MCP servers are identity and authorization brokers
MCP connects clients to tools, resources, and prompts. The July 2026 MCP specification included additional authorization hardening and clearer routing behavior, but protocol compliance does not decide business entitlement. An MCP server can still become a confused deputy if it holds powerful credentials and accepts requests from lower-privilege clients.
- Use per-user or per-client authorization where the downstream action is user-specific.
- Do not pass tokens to APIs they were not issued for.
- Keep tool permissions narrower than the MCP server’s infrastructure role.
- Separate read, write, and administrative tools.
- Log the initiating user/agent, tool call, downstream target, and authorization result.
Internal APIs still need explicit authorization
Network location is not a sufficient identity. Internal APIs are frequently reachable by many workloads, shared clusters, VPN users, or compromised applications. Zero-trust service design authenticates the workload and authorizes each sensitive operation.
- Validate token issuer and audience.
- Authorize service identity to explicit functions and resources.
- Segment sensitive APIs from general application networks.
- Use schema and resource limits for machine callers.
- Do not expose administrative endpoints simply because they are internal.
AI agents make behavioral controls more important
Traditional service accounts often call a stable set of endpoints in predictable sequences. AI agents may legitimately vary their behavior, but that does not mean 'anything goes.' Establish bounds: allowed tools, destinations, data classes, call rates, and action categories.
| Behavior signal | Possible concern |
|---|---|
| New internal API family | Agent scope expansion or prompt/tool manipulation |
| Sharp increase in object diversity | Enumeration or runaway workflow |
| Read followed by unrelated external write | Possible data exfiltration path |
| Repeated denied admin calls | Permission probing or bad tool planning |
| New egress destination | Compromised tool or unsafe connector |
Keep credentials out of model context
AI agents should not need to read raw API secrets to use a tool. The tool runtime can hold or mint credentials and return only task results. This keeps secrets out of prompts, memory, transcripts, and model-visible error messages.
A governance model for non-human API identities
- Discover service accounts, API keys, certificates, managed identities, agents, and MCP servers.
- Assign accountable owners and business purpose.
- Replace static secrets with short-lived identity where feasible.
- Scope every identity to explicit APIs and operations.
- Separate user delegation from workload authority.
- Require stronger approval for high-impact agent tools.
- Monitor machine behavior and cross-service sequences.
- Recertify and remove unused identities and credentials.
- Include non-human identities in incident response and access reviews.
Frequently asked questions
What is a non-human identity?
It is an identity used by software rather than a person, such as a service account, workload identity, API key, certificate, CI/CD principal, automation account, or AI agent.
Are AI agents just service accounts?
They may use service-account infrastructure, but agents can select tools and actions dynamically, so permission boundaries, delegation, tool governance, and behavioral monitoring need extra attention.
How should MCP servers authenticate to internal APIs?
Use normal workload or delegated identity mechanisms with correct token audience, scopes, and downstream authorization. Avoid a universal administrative credential.
Why are long-lived API keys risky?
They are easy to copy, often weakly attributable, and may remain usable long after ownership or business need changes.
Do internal APIs need authorization if the network is private?
Yes. Private network reachability does not prove that the calling workload is authorized for a specific object or function.
Sources and further reading
- Model Context Protocol — 2026-07-28 Specification — current protocol and authorization-hardening context
- NIST — Security Considerations for AI Agents — 2026 agent-security risk summary
- OWASP MCP Security Cheat Sheet — defensive MCP implementation guidance
- OWASP API Security Top 10 — 2023 — authentication, authorization, inventory, and resource risks
Protect APIs with runtime context, not just static rules
Ammune helps security teams discover APIs, understand normal behavior, detect abuse and authorization anomalies, and apply runtime protection across modern API environments.