Why API Keys and Service Accounts Can’t Govern AI Agents

Traditional API key security for AI agents fails because static credentials were built for predictable software, not autonomous decision-making.

While API keys authenticate connections and service accounts establish ownership at creation, neither mechanism can validate if a specific action was actually authorized by a human at the exact moment of execution.

The consequences of this security gap are severe. In April 2026, a Cursor AI agent deleted a production database that belonged to PocketOS, a car rental SaaS platform. The agent was behaving exactly as designed: it searched for available tools, found a credential with broad authority, and acted on it.

According to The New Stack, the agent was assigned to a routine staging task and ran into a credential mismatch. But instead of waiting for authorization from a human, it scanned the codebase for another way to proceed and found an API token with excessive authority.

To safely deploy autonomous systems, enterprise security teams are moving away from the static credentials of traditional machine identity models and adopting authorization at the execution plane.

Why AI agents break traditional machine identity models

AI agents differ from traditional non-human identities (NHI) in two fundamental ways that affect how credentials must work. Static provisioning and enumerable actions no longer apply when systems can make autonomous decisions at runtime.

Deterministic workflows vs. autonomous decision-making

Traditional machine identities execute deterministic workflows. Consider how legacy systems operate in practice: a cron job runs a backup script at 2 AM every night, an API integration syncs customer records on a rigid schedule, and a service account authenticates a deployment pipeline following identical steps every single time.

The entire set of actions a traditional machine identity will take is enumerable directly from its source code. Behavior only changes when the code changes, ensuring new actions pass through rigorous review and testing pipelines.

AI agents produce actions dynamically at runtime by interpreting natural language instructions. If two agents receive the exact same prompt, they might take entirely different paths depending on the available tools, environmental context, or underlying model version. Because their behavior changes without any code modifications, driven simply by a revised system prompt or a new model checkpoint, their potential actions cannot be enumerated in advance.

The scope problem: agents decide at runtime, not at provisioning

Traditional machine identities are provisioned with a fixed scope. A GitHub deploy token is bound to one repository, a Snowflake service account reads one schema, and a Stripe API key belongs to a specific subaccount. Because scope is decided at provisioning time and rarely changes, enforcing the principle of least privilege is highly tractable.

AI agents require broad capabilities to serve open-ended requests. A single coding agent might legitimately need read and write access to an entire repository graph, the ability to execute shell commands, and credentials to query internal services. This is not a case of over-provisioning; it is the baseline access required to complete unpredictable tasks.

The principle of least privilege must evolve. It has to move away from the static credential layer and shift to the moment of action. While the credentials themselves remain necessarily broad, actual authorization must happen at runtime by evaluating specific tool calls against the user request that prompted them.

3 structural flaws in API key security for AI agents

API keys were designed to authenticate applications, not to authorize autonomous decisions. Three structural limitations make API keys unsuitable for AI agents. These gaps create accountability blind spots, persistence risks, and scope violations that traditional access controls cannot address.

1. No ownership, no accountability

API keys merely authenticate a connection. If the key is valid, the target tool executes the request. Because they carry no ownership record, an audit log will only show that a key was used to delete a database. It will never show which human authorized the agent to perform that destructive action.

This lack of accountability creates severe incident response bottlenecks. When security teams need to trace an action back to a responsible human, API keys leave them blind, forcing reliance on external and often outdated documentation to reconstruct what happened, who triggered it, and whether it was ever authorized.

2. Static credentials with no expiration

Once an agent holds an API key, that credential persists indefinitely until it is manually revoked. If the agent is compromised or begins hallucinating, the key continues to work.

Manual rotation is the only available revocation mechanism, but it is highly disruptive because it breaks every downstream system relying on that key. The longer a credential stays active, the greater the risk it will be discovered by an attacker, misused beyond its intended scope, or simply forgotten by the provisioning team.

3. Overbroad scope by design

API keys almost always grant access to everything the issuing account can reach. A Stripe API key might hold full read and write access to customer data and billing records, while a cloud provider API key could allow unrestricted resource deletion across an entire account.

Because most APIs lack support for granular key permissions, this overbroad design fundamentally violates the principle of least privilege. If an agent only needs read access to customer records but holds an API key granting delete permissions, a simple error or compromise can trigger a catastrophic blast radius. The PocketOS incident is a precise illustration of this: the agent found a token with delete authority, and because nothing in the credential model prevented it from using that token, it did.

When an agent finds a token beyond its task

The PocketOS incident perfectly illustrates how these three failure modes combine to create production disasters. While the Cursor AI agent was assigned a task requiring highly limited database access, its autonomous search for credentials led it to an API token with full delete authority.

Because the token lacked scope restrictions, expiration windows, or runtime validation mechanisms, the system accepted the command. The agent behaved rationally within its design constraints, proving that the failure was strictly architectural. API keys are simply incapable of encoding the limitations required for autonomous action.

Why service accounts fall short for autonomous agents

Service accounts offer a slight improvement over API keys by establishing ownership at creation, but still contain critical gaps when applied to AI agents. Control plane visibility helps answer which agents exist and who owns them, but it does nothing to validate who authorized a specific action right now.

Establishing ownership at the control plane

When a human administrator provisions a service account, control plane tools like Microsoft Entra Agent ID, ServiceNow, or Saviynt can track its lifecycle. These tools flag orphaned accounts and provide security teams with critical visibility into what would otherwise be invisible automation.

This visibility solves the agent sprawl problem by answering exactly which agents are running and who owns them. This is a vital fix considering the Cloud Security Alliance reports that 82% of enterprises currently have unknown agents operating in their environments.

The execution plane failure

Despite these benefits, service accounts still fail at the execution plane. Ownership is only recorded at creation and is never validated at runtime.

When the agent leverages that service account to call a tool, the system only knows who created the agent. It has no way of knowing whether that human actually authorized the specific action taking place in the present moment. Accountability is established at birth, but authorization is entirely missing at execution.

No runtime check between registration and action

Service accounts rely on permissions assigned at creation that remain valid until explicitly changed; there is no mechanism to intercept an action at runtime and validate its scope against the current request.

If an agent has a valid service account holding credentials that permit database deletion, and every static check passes, the deletion will execute. No policy engine sits between the agent and the database to ask whether this specific deletion should happen right now, under current conditions, without human approval.

When ghost agents keep running after people leave

When an employee leaves an organization, their personal user account is typically decommissioned within hours. But the AI agents they created often continue operating on service account credentials that are disconnected from the employee's lifecycle, creating autonomous entities executing tasks with no accountable human attached.

Control plane tools can flag these orphaned accounts, but flagging is not containment. For a deep dive into how runtime authorization solves the ghost agent problem through cryptographic credential voiding, see our Know Your Agent explainer below.

The shift to runtime authorization

Static credentials cannot validate autonomous decisions. To govern AI agents safely, authorization must move from the provisioning layer to the execution layer.

By intercepting agent tool calls at the Model Context Protocol (MCP) layer before they reach target systems, organizations can validate each action against the specific context and human intent that triggered it. Because MCP functions as the standard tool access interface across agent frameworks including LangChain, Relevance AI, and Microsoft Copilot Studio, a policy engine operating at this layer enforces consistent authorization regardless of how the agent was built. Rather than provisioning credentials with broad, permanent access, authorization is bound directly to the tool call itself.

Policy thresholds determine when human approval is required. Routine operations that fall within predefined parameters execute automatically once the agent's credential is validated. When an agent attempts an action that exceeds those thresholds, such as provisioning infrastructure, moving money above a defined limit, or accessing sensitive data stores, the policy engine pauses the request and prompts the responsible human for explicit approval before the tool is reached. The credential issued for an approved action exists only for that specific operation and expires immediately afterward.

The full architecture of how execution plane governance works, including how verifiable credentials replace static API keys and how the MCP interception layer enforces policy across agent frameworks, is covered in detail here.

Where accountability meets autonomy

The shift from static credentials to runtime authorization is the operational foundation of Know Your Agent (KYA), a framework that validates which agent is acting, under whose authority, and within what scope at the moment of execution.

Where API keys and service accounts answer the question of who created the agent, KYA answers the question that actually matters at runtime: who authorized this specific action right now. If you want a full treatment of the framework and how it extends established identity principles to autonomous agents, the complete Know Your Agent explainer covers it in detail.

The gap between AI agent capabilities and credential models is widening. Organizations deploying autonomous systems need governance that validates authorization dynamically during the actual tool call, not just once during provisioning.

Agents are already running in your environment

The question is whether you're effectively governing them and the actions they take.

API keys and service accounts were the right tools for a world where machine identities followed scripts, but AI agents don't follow scripts, and static credentials aren't enough.

1Kosmos closes this gap at the execution plane, binding every agent action to a verified human before the tool is ever reached.

Visit the 1Kosmos AI agents page to see how it works, or book a demo to see it firsthand.