API security for AI agents: why static keys no longer fit

At a glance

What this is: This is a Raidiam thought leadership post arguing that enterprise API security is failing under AI agent and sensitive-data exposure because static secrets and weak authorization no longer match how modern consumers and systems interact.

Why it matters: It matters because IAM, NHI, and emerging agent governance programmes all depend on per-request identity assurance, scope control, and lifecycle discipline when APIs become the control plane for sensitive actions.

By the numbers:

• Over 80% of organisations fell into the “Act Urgently” category, exposing sensitive APIs with weak protections.
• The study reviewed 68 enterprise APIs outside heavily regulated contexts like Open Banking.

👉 Read Raidiam's analysis of API security for AI agents and sensitive data

Context

API security is no longer only about transport encryption or gateway placement. When APIs carry customer data, payment initiation, and AI agent-driven requests, the real problem is whether the requesting identity can be verified, constrained, and audited at the moment of use.

Raidiam’s findings point to a familiar identity failure pattern: static API keys, long-lived shared secrets, and coarse-grained authorization remain common even where sensitive data is exposed. That creates avoidable privilege persistence across NHI and agent-facing workflows, which is increasingly misaligned with how modern API ecosystems actually operate.

Key questions

Q: How should security teams secure sensitive APIs used by AI agents?

A: Security teams should treat AI agent API traffic as delegated identity, not just application traffic. That means short-lived credentials, request-level authorization, federated trust, and auditable scope checks for every sensitive action. If the API can move money, reveal data, or trigger workflows, the caller must be verified at execution time, not assumed trusted after initial authentication.

Q: Why do static API keys create so much risk in enterprise environments?

A: Static API keys create persistent access because they remain valid long after the original task, user, or integration context has changed. Once exposed, they are hard to scope tightly and slow to revoke across distributed systems. That makes them useful for convenience but dangerous for sensitive APIs that can expose data or initiate transactions.

Q: What breaks when coarse-grained authorization is used for sensitive APIs?

A: Coarse-grained authorization breaks when one token authorizes too many actions, accounts, or systems. It expands the blast radius of any stolen credential and makes it difficult to separate low-risk requests from high-risk ones. In practice, it turns an authentication success into an overly broad trust decision.

Q: Who is accountable when an AI agent makes an unauthorized API call?

A: Accountability should follow the delegation chain, not just the last system that executed the request. The organisation that issued the trust, defined the scope, and allowed the agent or integration to operate remains responsible for the resulting action. This is why provable delegation and auditability matter more than simple login success.

Technical breakdown

Static API keys and shared secrets create persistence risk

Static API keys and shared secrets are durable credentials, so a compromise can outlive the original use case and remain valid across multiple systems. In practice, they behave like standing privileges: they are simple to deploy, hard to govern at scale, and easy to forget once embedded in code, partner integrations, or service workflows. The security issue is not just theft, but persistence. When credential lifetime is decoupled from session or task duration, the blast radius expands and revocation becomes a delayed, manual process.

Practical implication: replace durable shared secrets with short-lived, bound credentials wherever API risk is material.

Fine-grained authorization is the control that actually limits API abuse

Authentication answers who or what is calling the API, but authorization decides what that caller can do on each request. Coarse-grained authorization often grants more access than the transaction requires, especially when one token is reused across multiple accounts or functions. For sensitive enterprise APIs, that creates an over-privilege problem rather than a simple access problem. Per-request authorization, scope enforcement, and contextual policy checks narrow the available action set and reduce the value of a stolen credential or impersonated agent.

Practical implication: enforce request-level authorization and scope checking for every sensitive API action.

AI agents make API identity a delegation problem

AI agents do not just consume APIs, they can act as intermediaries that initiate actions, combine data sources, and execute sequences on behalf of users. That changes the control question from "can a client authenticate?" to "can the enterprise prove which actor initiated the request, what scope was delegated, and whether the action still matches the original intent?" Standards such as OpenID Federation, software statement assertions, mutual TLS, and certificate-bound tokens help establish that chain of trust. Without that, agent-driven traffic looks like ordinary API traffic even when it is functionally a delegated identity event.

Practical implication: design API trust models for delegated machine action, not just browser-style authentication.

Threat narrative

Attacker objective: The attacker or imposter aims to reach sensitive enterprise data and perform unauthorized actions through trusted API pathways.

1. Entry occurs through exposed enterprise APIs that rely on static API keys or long-lived shared secrets, giving attackers or imposters durable access paths.
2. Escalation follows weak authentication and coarse-grained authorization, which let a caller reuse one credential across multiple sensitive requests and systems.
3. Impact is sensitive-data exposure, unauthorized transaction initiation, regulatory penalties, and loss of customer trust when APIs cannot reliably distinguish a user from an agent or imposter.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static API keys are standing privilege by another name: Raidiam’s findings reinforce that durable API credentials behave like persistent access, not contextual trust. When sensitive APIs are protected by long-lived shared secrets, the organisation inherits a revocation problem as much as an authentication problem. The practitioner conclusion is straightforward: if the credential can survive the transaction, it can also survive the compromise.

Identity blast radius is now determined at request time, not issuance time: Coarse-grained authorization fails because the token or key often outlives the specific action it was meant to authorize. That is a bad fit for enterprise APIs that can move money, reveal personal data, or trigger downstream workflows. The issue is not simply over-permissioning at provisioning, but over-permissioning at execution. Practitioners should treat request-level scope as the real boundary of control.

AI agents turn API access into delegated machine identity: The article is right to frame AI agents as a new consumption layer, but the deeper governance shift is that the enterprise must validate delegated intent, not just caller identity. OpenID Federation, software statement assertions, and certificate-bound tokens matter because they make the delegation chain inspectable. The practitioner takeaway is that API governance now has to understand who initiated the action, who executed it, and whether the delegation still holds.

Standards-based trust is now the only scalable way to separate customers, systems, and agents: Bespoke API security will struggle as agent-mediated traffic grows. Federation and bound tokens create a common trust vocabulary across human users, service accounts, and AI intermediaries, which is exactly what fragmented API estates lack. The discipline shift is from protecting endpoints to governing identities and delegations across the full API lifecycle.

From our research:

• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• Forward view: The AI Agents: The New Attack Surface report shows why governance must move from static credential control to delegated identity oversight.

What this signals

Identity teams should expect API governance to converge with NHI and agent oversight. Once APIs become the primary channel for customers and AI agents, the old split between application security and identity security stops working. The programme signal is clear: request-level trust, scope enforcement, and auditability are now core identity controls, not optional API hardening.

Standards-based trust will matter more than bespoke gateway logic. Federated identity, certificate-bound tokens, and per-request policy checks are the sustainable pattern for ecosystems that have to distinguish users, service accounts, and AI intermediaries. This is where API security starts to resemble workload identity governance more than classical perimeter protection.

32.4% of security budgets going to secrets management and code security shows how expensive credential sprawl has become, according to our research. For practitioners, the signal is that spending is shifting toward reducing trust persistence, not just detecting misuse after the fact.

For practitioners

• Replace long-lived shared secrets Move sensitive API consumers onto short-lived, certificate-bound credentials so a compromised key cannot continue to act across unrelated transactions. Tie credential lifetime to the smallest practical use case and make revocation immediate.
• Enforce per-request authorization Check scope, context, and intent on every sensitive request rather than trusting a token once at login or provisioning time. Use fine-grained policy to limit payment, data, or account-level actions separately.
• Adopt federation for delegated callers Use OpenID Federation and software statement assertions to verify who the API consumer is and what it is authorised to do before allowing sensitive access. This is especially important where AI agents broker user actions.
• Bind trust to the client certificate Use mutual TLS and certificate-bound tokens where API compromise would have material impact. This prevents token interception from becoming an immediate replay path and strengthens proof of client identity.

Key takeaways

• Static API keys and weak authorization create persistent trust that does not match the sensitivity of modern enterprise APIs.
• Raidiam’s review of 68 APIs found that more than 80% of sensitive exposures sat in an “Act Urgently” risk band.
• Security teams should move to short-lived credentials, request-level scope checks, and federated trust for delegated callers.

Key terms

• Static Api Key: A static API key is a long-lived credential used by an application or integration to authenticate to an API. It is easy to deploy but hard to govern, because the same secret can keep working long after the original business need, increasing exposure if it is copied, leaked, or reused.
• Fine-Grained Authorization: Fine-grained authorization limits what a caller can do on each specific request rather than granting broad access once and assuming it stays safe. In API security, this is the control that prevents one valid identity from becoming a universal pass to data, payments, or account actions.
• Delegated Identity: Delegated identity is a trust model where one actor, such as an AI agent or integration, performs actions on behalf of another. The security challenge is proving the original intent, scope, and accountability chain so the delegation cannot silently expand into unauthorized activity.
• Certificate-Bound Token: A certificate-bound token is tied to a specific client certificate so it cannot be freely replayed from another device or session. This reduces interception risk and strengthens proof that the caller presenting the token is the same entity that was originally trusted.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Raidiam: API Security and AI Agents: Safeguarding Sensitive Enterprise Data. Read the original.