How AI Agents Are Rewriting Cloud Secrets Management

One of the biggest threats to your cloud environment could very well be a credential with no username, no physical location, and no predictable expectations of what it’ll do in the future.

These days, AI agents aren’t just responding to prompts and creating code snippets. They can call out APIs, interact with databases, invoke tools, provision resources, and act within your cloud environments with little to no human oversight. That undermines a core tenet of traditional secrets management: that a credential is tied to a specific user or workload that will perform a certain set of tasks in a way that the outcome is foreseeable.

For years, secrets management has been about keeping those secrets safe, rotating them frequently, and limiting who or what can get at them. Those are all still valid concepts, but agents bring new challenges. It’s no longer about knowing whether an agent can access a secret. We have to understand what it’s permitted to do, under what circumstances, and how long that permission should last.

The secret is no longer the problem

There are already an enormous number of non-human identities out there in your cloud environments. Applications, containers, CI/CD systems, service accounts, etc., all need credentials to communicate with other services and systems. Microsoft calls them “non-human identities,” and now AI agents are becoming another increasingly important class.

The problem, however, is that while a conventional workload would operate within a clearly defined scope where it might use a credential to pull data from a database or send an event, an AI agent is much more dynamic. It can determine what tools it needs to use, then make decisions based on what it finds, and potentially even chain several actions together.

That means giving an agent a powerful service account is problematic. If that credential grants access to 12 different systems, the agent technically can do whatever it wants with all 12, even though the immediate task at hand might require access to just one.

This particular problem is quickly evolving into something that looks less like secrets management and more like identity management for agents.

Agents need identities, not just credentials

A common approach to this issue is to treat agents as identities themselves, instead of allowing them to inherit the permissions of the application they’re running as. Google Cloud, for instance, has created an agent identity model that provides agents with a unique identity to use when making calls to cloud resources. Microsoft did something similar with Entra Agent ID, which provides a dedicated identity layer for AI agents.

What makes that important is that an agent’s identity becomes a central factor in authorization decisions. As opposed to evaluating whether a given service account is authorized to access a resource, security teams can start asking what this specific agent is allowed to do.

This also allows you to add some much-needed context that most traditional secrets lack. An agent that’s doing standard reporting might need read-only access to a database, but have no reason to edit entries. An agent tasked with performing remediation might need write access to a specific set of resources. By treating these as separate identities, you can enforce that restriction, as opposed to relying on the agent itself to only access what it’s supposed to.

Short-lived credentials 

The next step is reducing the total amount of access an agent needs to have at all. Long-lived API keys are already considered a somewhat uncomfortable security primitive. If they are leaked or compromised in any way, an attacker can keep using them until someone discovers the leak and revokes them. Giving a similarly long-lived credential to an autonomous agent opens up a new opportunity for exploitation, especially when the credentials can be shared across tools and systems.

Workload identity and short-lived credentials present a different paradigm. Instead of having a permanent secret embedded within the application or agent, the workload retrieves temporary credentials when it needs to perform a given action. AWS’s recommendations on how to secure AI agent access demonstrate this trend, with a focus on limiting access patterns between agents, tools, and AWS resources instead of providing agents with wide-ranging, long-lived credentials.

The benefit is clear: the access expires. While it doesn’t remove the need for authorization, it reduces the value of a credential if it gets stolen. An attacker with a short-lived token has a much shorter window in which to exploit it than someone who steals a permanent API key from an environment variable. For cloud-native organizations that already utilize workload identity, this is less a new technology than a continuation of an existing tenet: Provide workload identities and temporary access instead of long-lived secrets.

Identities do not equal permissions

Short-lived credentials only solve half the issue, though. A temporary credential with overly permissive access is still too permissive. This is where agent-specific access becomes critical. Agents should have only the permissions required to complete their immediate task, and their permissions should correspond with the tools they use. A customer-facing agent that can read records shouldn’t necessarily be able to delete those records. An agent that can restart a service shouldn’t be able to modify the service’s IAM policy.

OWASP’s recommendations for agentic applications point out dangers such as excessive agency, insecure tool usage, and the potential for agents to act autonomously in ways that impact the physical world. This forces cloud security teams to think more in terms of fine-grained authorization. Permissions need to take into account the specific agent in question, the requested operation, the resource accessed, the tool invoked, and most importantly, the context surrounding the request. Some organizations might still want a human-in-the-loop approach for sensitive actions instead of allowing an agent to instantly turn authorization into an irreversible act.

The new secret 

None of this implies that secret management is dying or dead. Passwords, API keys, certificates, and tokens will continue to exist within enterprise environments for the foreseeable future. What is shifting is where the security boundary exists. Traditional secrets management focused primarily on keeping credentials hidden from unauthorized eyes. Within an agent-centric ecosystem, organizations need to be able to manage what an identity can do once it authenticates. That is a far more complex challenge. AI agents can act continuously, leverage multiple tools, discover unforeseen data, and adjust their plans according to discoveries. That’s why it’s important to ensure that their security model doesn’t rely entirely on a static credential stored securely in a vault.