Category: Access Management

The best alternatives to HashiCorp Vault fall into three primary architectural categories: cloud-native managed secrets services, developer-focused secrets managers, and secretless non-human identity platforms. While traditional alternatives continue to store static credentials inside encrypted databases, modern platforms eliminate static secrets by issuing scoped, just-in-time access directly to workloads. For organizations managing non-human identities such as deployment pipelines, container workloads, and autonomous agents, secretless architectures represent the most secure alternative to managing a central secrets vault.

Centralized secrets vaults require ongoing operational maintenance, continuous token rotation, and complex replication topology design. Storing static credentials inside any centralized database creates an attractive target for credential compromise and requires specialized engineering teams to monitor storage backends, seal states, and disaster recovery. Modern security architectures address these operational burdens either by offloading vault infrastructure to managed cloud providers or by removing static credentials entirely through verified runtime identity.

What are the best alternatives to HashiCorp Vault for managing secrets?

Evaluating alternatives to HashiCorp Vault requires classifying solutions by their underlying architectural approach rather than treating all secrets tooling as identical. The three core alternatives to a self-hosted HashiCorp Vault deployment are cloud-provider key management services, developer-centric synchronization vaults, and secretless non-human identity platforms.

Secrets management architectures have evolved past the initial model of centralizing static tokens into an encrypted database. While early secrets managers focused on safeguarding static API tokens and database credentials, modern engineering environments feature dynamic workloads that need short-lived authorization rather than stored secrets.

Security teams choosing an alternative should determine whether their goal is simply replacing the underlying vault software or eliminating the operational overhead of managing static secrets altogether.

Why do engineering teams replace HashiCorp Vault?

Engineering teams replace HashiCorp Vault primarily to reduce operational complexity, escape restrictive software licensing terms, and lower the infrastructure burden of maintaining dedicated vault clusters. Running a self-hosted vault demands continuous platform engineering resources to manage high-availability storage backends, automated unsealing protocols, routine software upgrades, and multi-region synchronization.

Dedicated vault architectures also create significant developer friction. Application developers must learn proprietary API conventions, configure client token renewals, and handle vault connection failures gracefully inside application logic. When a vault cluster becomes unresponsive or enters a sealed state, dependent production services cannot authenticate, creating system-wide downtime.

Storage of static credentials represents another core reason teams migrate away from legacy vaults. When engineering teams store static secrets in a vault, those secrets still leak into environment variables, container layers, CI/CD run logs, and developer workstations. Managing secrets by merely storing them in a central repository fails to protect organizations against token theft once the secret is retrieved by a workload.

How do cloud-native secrets managers compare to centralized vaults?

Cloud-native secrets managers replace self-hosted vaults by delegating infrastructure management, high availability, and encryption-at-rest directly to major cloud providers. These services integrate natively with cloud identity and access management roles, eliminating the need to deploy and patch dedicated server instances or configure complex unsealing keys.

Cloud provider services simplify day-one operations for engineering teams committed to a single cloud ecosystem. Workloads running on managed cloud infrastructure authenticate directly using instance metadata and assigned runtime roles, bypassing the need for initial secret introduction problems common to traditional vault installations.

Multi-cloud enterprises, however, face architectural limitations when relying solely on cloud-native secret stores. Each cloud provider implements proprietary access control policies, unique API structures, and distinct audit logging formats. Platform teams operating across multiple cloud providers must maintain duplicate access policies and disparate operational workflows, recreating administrative complexity.

How does secretless access eliminate vault-stored credentials?

Secretless access platforms eliminate vault-stored credentials by replacing static API keys, tokens, and database passwords with real-time, identity-verified authorization. Instead of storing sensitive credentials in a vault and requiring applications to fetch them at runtime, workloads receive temporary, tightly scoped credentials minted dynamically for specific operations.

Non-human identities such as CI/CD pipelines, containerized microservices, background jobs, and autonomous agents represent the majority of access requests in modern cloud infrastructure. Traditional vaults treat these identities as consumers of static tokens, which leaves long-lived secrets susceptible to extraction from memory, logs, or compromised containers.

Runtime identity attestation evaluates the cryptographic provenance of a calling workload, confirming its binary hash, cloud environment, container namespace, and code repository before granting access. By validating identity at the moment of execution, platform teams remove the need to maintain static credentials inside vault databases, avoiding credential lifecycle management entirely.

Which alternative to HashiCorp Vault fits your security model?

Selecting an alternative to HashiCorp Vault depends on your organization’s deployment environment, engineering capacity, and security strategy regarding static versus dynamic credentials. Security architects should evaluate alternative solutions against specific infrastructure requirements:

• Single-Cloud Infrastructure: Teams running workloads strictly inside one cloud provider achieve the lowest operational overhead by adopting that provider’s native secrets management service, leveraging native IAM policies without cluster management.
• Existing Vault API Investments: Organizations with extensive codebase integrations written specifically for Vault APIs that require open-source licensing typically evaluate community-maintained open-source forks to minimize code rewrites.
• Developer Experience and App Configs: Early-stage development teams focused primarily on synchronizing configuration files and environment variables across staging environments benefit most from developer-centric SaaS secrets managers.
• Zero-Trust and Non-Human Identity Modernization: Enterprises managing microservices, automated pipelines, and artificial intelligence agents across diverse environments achieve the highest resilience by adopting secretless identity architectures that remove stored secrets from the attack surface.

Security teams evaluating these options must weigh the recurring labor of operating vault infrastructure against the security benefits of removing stored credentials from application memory.

How to evaluate your migration path away from HashiCorp Vault

Platform engineering teams planning a migration away from HashiCorp Vault should begin by cataloging the exact types of secrets stored within their current clusters. Auditing secrets usage reveals whether your workloads consume static third-party API keys, database credentials, internal service tokens, or public key infrastructure certificates.

Categorizing secrets by consumer type establishes whether your primary migration challenge is developer tooling or non-human workload authentication. Applications that rely on static database passwords can frequently be modernized to consume short-lived identity tokens, removing the need to migrate those secrets into a replacement vault.

Identity security assessments determine whether replacing HashiCorp Vault with another centralized vault solves your core security challenge. While swapping vault engines can reduce software licensing costs or cluster maintenance, migrating to secretless non-human identity access eliminates credential rotation failures, unauthorized token reuse, and static secret storage risks at the architectural level

Three services crashed at 3 AM. The rotation job failed. Your team got paged. Six hours later, you had a working incident report.

Meanwhile, your data pipeline agent extracted customer data for hours before anyone noticed. Your logs show the agent made the queries. You can’t prove it wasn’t an attacker.

Both scenarios share the same root cause: you’re managing credentials like it’s 1995.

Compromised identities account for over 70% of cloud breaches. Stolen credentials are tied to 86% of security breaches. Your API key costs $10 on the criminal market.

You’re not managing credentials. You’re managing a liability.

The Operational Tax of Manual Credential Lifecycle Management

Every 90 days, your team stops shipping features to rotate credentials. Someone writes a rotation job. Someone schedules the maintenance window. Someone stays up late monitoring failures. Someone gets paged when it breaks.

For microservices, rotation failures cascade. For AI agents, they run 24/7 without human intervention – rotate too slow and the agent crashes, rotate too fast and you cause outages.

When credentials leak:

• Your API key works for 6 months
• The attacker has unlimited access to everything it touches
• You won’t notice for ~88 days
• Breaches caused by compromised credentials cost $4.50M on average
• The credential itself cost an attacker $10

Your infrastructure is secured by a $10 secret that lives forever.

What SPIFFE Actually Is

SPIFFE = Secure Production Identity Framework For Everyone.

Instead of: “Here’s a secret, rotate it every 90 days.”

SPIFFE says: “I’ll issue you a certificate valid for 1 hour. When it expires, you get a new one automatically. No pre-shared secrets. No rotation jobs.”

Three building blocks:

SPIFFE ID – a unique URI identifying the workload, e.g. spiffe://example.org/ns/production/sa/payment-service. Public identifier, not a secret.

SVID (SPIFFE Verifiable Identity Document) – the credential itself. X.509 cert or JWT. Short-lived. Auto-rotates. Delivered via local API – no manual distribution.

Attestation – cryptographic proof of identity derived from environmental signals (Kubernetes node identity, cloud metadata, container runtime). No pre-shared secrets.

How it works: Workload starts, requests identity, SPIRE server verifies environment, issues a 1-hour certificate, workload uses it, new one issued before expiry.

What SPIFFE Promises

No rotation windows. Certificates rotate hourly. Zero downtime. Zero 3 AM pages.

Breach window shrinks to 60 minutes. If a credential leaks, it’s invalid in an hour – not six months.

No credential distribution. No mounted secrets, no shared API keys – workloads prove identity cryptographically.

Mutual authentication. Service A proves identity to Service B. Both sides verified.

Fine-grained, scoped access. Payment service gets access to the payments DB only. Nothing else.

Scales without operational burden. Your 150th microservice doesn’t need a new rotation job. Same system, zero overhead.

This is the pitch – and it’s a good one. SPIFFE has been the “right answer” for workload identity for nearly a decade.

So why isn’t everyone using it?

The Reason SPIFFE Stalled: The Ecosystem Doesn’t Speak It

Here’s the uncomfortable truth almost no SPIFFE content will tell you: SPIFFE only works where both sides of the conversation support it.

And most of the things your workloads actually talk to – don’t.

• S3 doesn’t accept SPIFFE SVIDs. It accepts AWS access keys or STS tokens.
• Snowflake, Postgres, MySQL, MongoDB Atlas – none authenticate SPIFFE identities natively.
• Stripe, Twilio, OpenAI, Salesforce, GitHub, Datadog, every SaaS API your stack depends on – they want an API key or OAuth token. Not an SVID.
• Your legacy internal services – the ones written before 2021 – still expect a bearer token or a username/password.

SPIFFE handles east-west traffic beautifully: service-to-service mTLS inside a mesh. But the moment a workload needs to read an S3 bucket, query Snowflake, call Stripe, or hit any of the hundreds of APIs your business runs on – you’re back to static API keys. Back to vaults. Back to 90-day rotation jobs. Back to the $10 forever-credential problem.

This is why most SPIFFE rollouts die mid-implementation. Teams deploy SPIRE, secure 20% of their traffic, and then run headlong into the 80% of external and legacy dependencies that will never support SPIFFE. The rotation pager keeps firing. The vault keeps sprawling. The promise of identity-first security evaporates.

SPIFFE is right. The ecosystem is just too big to rewrite.

The Hush Retrofit: SPIFFE-Grade Identity on Every Resource You Already Have

This is where Hush comes in.

Instead of waiting for S3, Snowflake, Stripe, and your legacy APIs to adopt SPIFFE (they won’t), Hush uses SPIFFE/SPIRE as the attestation layer – and brokers access to everything else.

The flow:

1. A policy is created with the Hush solution. Workload identity (pod, machine, process), target service/resource (Snowflake, Cloud federated resources) and role or permissions (READ Users Table, View Role on OpenAI)
2. Workload starts. No embedded credentials. No long lived keys.
3. Hush validates the SPIFFE identity, checks policy, and issues a fresh, short-lived, scoped “legacy” credential – an AWS STS token, a database password, a rotating API key – whatever that resource actually accepts.
4. The workload does its job.
5. Hush revokes the credential when the task completes,  no long-lived secrets left lying around.

Same cryptographic identity guarantees as SPIFFE. Same short lifetimes. Same scoped access. But it works on the resources you already run – without asking AWS, Snowflake, Stripe, or your own legacy services to change a single line of code, without waiting for the entire aco-system to adapt to the new standard.

SPIFFE attests. Hush brokers. The ecosystem just works.

Real-World Scenario: Microservices at Scale

You run 150 microservices across multiple clusters. Each one needs database access, third-party APIs, cross-service communication, and S3.

Without Hush: Pure SPIFFE gets you mutual TLS between services. Good. But your payment service still holds a 6-month Postgres password to access the payments DB, a long-lived Stripe key, and an AWS access key for S3. Rotation jobs, vault entries, and 3 AM pages remain.

With Hush: The payment service is attested by SPIRE at startup. When it needs the payments DB, Hush issues a Postgres credential scoped to the payments schema. When it needs Stripe, Hush issues a short-lived Stripe key scoped to the operations this service is authorized for. When it needs S3, Hush brokers an STS token scoped to the one bucket. Every credential is bound to the attested SPIFFE identity, every credential is short-lived, every credential is revoked when the work is done. The audit trail is cryptographically signed end-to-end – you can prove to regulators exactly which service made each access.

No rotation jobs. No vault. No 3 AM pages. No changes to Postgres, Stripe, or S3.

Real-World Scenario: AI Agents

Your data pipeline agent accesses: the customer database (read), the data warehouse (write to specific schemas), S3 buckets (output), transformation APIs.

Without Hush: The agent runs on one long-lived API key with full permissions to everything. An attacker gets it, extracts millions of records overnight, and your logs can’t distinguish the attacker from the agent.

With Hush: The agent is attested via SPIFFE/SPIRE at startup. Before each operation, it requests scoped, short-lived credentials from Hush – a read token for a specific customer table, a write token for a specific warehouse schema, an STS token for a specific output bucket, an API key scoped to specific transformation endpoints. Each credential is revoked when the task completes. A stolen credential buys the attacker a tiny window on a tiny slice of the system – and you can prove which requests were legitimate vs. anomalous.

The agent’s real identity is the SPIFFE attestation. The “legacy” keys are disposable.

Why This Matters Now

Credentials leaked 160% more in 2025 than in 2024. Your team probably hasn’t rotated this quarter. 70% of cloud breaches start with compromised identities. 86% of web application attacks involve stolen credentials. That $10 credential could be yours.

For microservices: Kubernetes adoption is standard. Thousands of services per org is routine. Manual secret management at this scale is a losing game.

For AI agents: Autonomous workloads are exploding. Data pipelines, ML training agents, ETL orchestrators, inference engines – every one of them needs identity. Today they mostly run on static API keys that never expire.

SPIFFE solved the identity problem years ago. The ecosystem just hadn’t caught up. Hush closes the gap.

SPIFFE as a Service : Without the Ecosystem Problem

Building SPIRE yourself takes months: highly available servers, agents on every node, certificate pipelines, multi-cloud federation, ongoing maintenance. And even after all of that, you still can’t talk to your databases or SaaSs without static keys.

Hush delivers the full stack as a managed service:

• Managed SPIRE – workloads get cryptographic identity automatically on startup. No infrastructure to build.
• Credential brokering – short-lived, scoped credentials for AWS, Snowflake, Postgres, every major SaaS, and your internal legacy services. Issued on demand, bound to SPIFFE identity, revoked when the task is done.
• Unified policy – one place to say “the payment service can access these resources, scoped this way, for this long.” No more per-system ACL sprawl.
• No code changes on the resource side. S3, Snowflake, Stripe, your legacy APIs – untouched.

For microservices: integrate via existing service mesh or sidecar.

For AI agents: a single Hush call, then on-demand credential requests as the agent works.

Your team focuses on shipping microservices and building better agents. Not managing credentials.

Getting Started

Pick one critical service or one autonomous agent. Replace its long-lived credentials with Hush-brokered, SPIFFE-attested, short-lived ones. Within weeks, you stop thinking about rotation for that workload. Within months, you wonder why you ever managed credentials any other way.

Start small. Expand as the wins compound. Stop rotating. Stop managing vaults. Stop losing engineering time to credential management.

Ready to Make SPIFFE Work Everywhere?

For platform, SRE, data, and ML engineering teams: See how Hush combines SPIFFE-grade attestation with short-lived, scoped credentials for every resource your workloads already depend on – without changing the resources themselves.

Last week, a malicious package sat on PyPI for less than an hour. It was pulled in by millions of projects as a transitive dependency. It silently harvested every secret on every machine that installed it, encrypted the haul with a hardcoded RSA key, and shipped it to an attacker-controlled server. Then it tried to pivot into Kubernetes, plant a persistent backdoor, and spread across every node in the cluster.

The package was litellm 1.82.8. The attacker didn’t compromise a cloud provider or exploit a zero-day. They uploaded a Python package. That was enough.

We want to walk through exactly how this worked, why the standard toolkit failed to stop it, and what a different security model looks like in practice.

How the attack worked

The compromised litellm 1.82.8 release (and 1.82.7, which was also affected) included a file called litellm_init.pth. Python’s site module processes .pth files automatically on every interpreter startup, before any application code runs, with no import statement required. Dropping a .pth file into a package is one of the most reliable code execution primitives available to a PyPI attacker: silent, automatic, and almost never audited.

Figure 1: The three-stage attack chain, from PyPI upload through direct and transitive installs to credential harvest, exfiltration, and Kubernetes persistence.

The payload ran in three stages:

Stage 1: Harvest. A Python script crawled the filesystem for everything a cloud attacker would want: SSH private keys and config files, .env files, cloud provider credentials ( ~/.aws/credentials, GCP Application Default Credentials at ~/.config/gcloud/, Azure CLI tokens at ~/.azure/), Kubernetes configs at ~/.kube/config, .gitconfig, shell history, and anything matching common secret filename patterns. It also hit cloud metadata endpoints directly: the AWS IMDS at http://169.254.169.254, GCP metadata at http://metadata.google.internal, and container credential endpoints, to capture ephemeral tokens that would never appear on disk.

Stage 2: Exfiltrate. The collected data was encrypted with a random AES-256-CBC session key. That session key was then wrapped with a hardcoded 4096-bit RSA public key, bundled into a tar archive, and POSTed to https://models.litellm.cloud/, a domain crafted to pass a casual glance as legitimate litellm infrastructure. Only the attacker held the RSA private key, so the payload was unreadable in transit to anyone else.

Stage 3: Persist and spread. If a Kubernetes service account token existed at /var/run/secrets/kubernetes.io/serviceaccount/token, the malware used the Kubernetes API to enumerate and exfiltrate all cluster secrets across all namespaces, then attempted to schedule a privileged alpine:latest pod on every node in kube-system. Each pod mounted the host filesystem at /host and wrote a persistent backdoor to ~/.config/sysmon/sysmon.py, registered as a systemd user service at ~/.config/systemd/user/sysmon.service. The same persistence routine ran on the local machine regardless of whether Kubernetes was present.

The blast radius extended far beyond anyone who explicitly ran pip install litellm. Any package declaring litellm>=1.64.0 as a dependency pulled in the compromised version automatically, including widely used AI frameworks. LiteLLM sees roughly 97 million monthly PyPI downloads. Most victims would have had no idea they were affected.

The attack was discovered by accident. The .pth launcher spawned a child Python process via subprocess.Popen. Because .pth files execute on every interpreter startup, that child immediately triggered the same .pth again, producing an exponential fork bomb. A developer at FutureSearch noticed their machine running out of RAM after an MCP plugin pulled in litellm 1.82.8 as a transitive dependency inside Cursor. A competent attacker would not have made that mistake. The window of exposure would have been measured in days or weeks, not hours.

Why your existing tools would not have caught this

Before getting to what Hush does, it is worth being specific about why the standard security stack fails against this class of attack.

Software composition analysis (SCA) and dependency scanning check known vulnerability databases. This was not a vulnerability. The package was legitimate code doing exactly what it claimed. No CVE was ever filed. An SCA scanner pointed at your lockfile after the fact would have found nothing.

Secret scanning looks for secrets committed to source control or present in CI logs. The secrets in this attack lived on developer workstations and in running service environments, not in git. Secret scanning would not have seen them.

Network egress controls might have caught the exfiltration POST to models.litellm.cloud, if you had strict allowlisting in place. Most environments do not. Developer laptops almost never do. And the domain was designed to blend in.

Vault and secrets management tools like HashiCorp Vault or AWS Secrets Manager reduce secret sprawl when used correctly, but they still issue secrets that land somewhere: in environment variables, in files, in memory accessible to any process running as the same user. A malicious package running in the same process space or as the same OS user can reach them.

The uncomfortable truth is that all of these controls are perimeter defenses. They assume the code running on your machines is trustworthy. Supply chain attacks invalidate that assumption at the root.

The structural problem: secrets are just files

It is tempting to frame yesterday’s attack as a PyPI moderation failure, or a litellm maintainer incident. Both of those things are true and worth fixing. But they do not explain why the attack was so effective or why rotating credentials after the fact is the best available response.

Every credential that was exfiltrated (AWS access keys, GCP ADC tokens, Kubernetes configs, SSH keys, .env API keys) shared one property: it was a long-lived, static secret sitting on disk. Secrets do not authenticate their reader. They do not know whether the process opening ~/.aws/credentials is your application or malware that arrived as a transitive dependency of a package you installed this morning. Possession is the entire security model.

Supply chain attacks are designed to exploit exactly this. A malicious package runs inside your trust boundary with the same filesystem permissions as the developer who installed it. It does not need to escalate privileges or bypass endpoint controls. It just needs to read files, which any process can do.

Telling developers to rotate secrets more frequently, use a vault, or avoid hardcoding does not change this. As long as access to a resource is gated by possession of a file, any code that can read files can compromise it. The rotation cadence just determines how long the window stays open after a theft.

What a different model looks like

At Hush, we build on a different premise: the credential should never exist on the machine in the first place. Access should be granted based on verified identity and evaluated policy, not on possession of a secret.

Here is what that means concretely for this attack:

Figure 2: How Hush neutralises each stage of the attack. No static secrets to harvest, runtime anomaly detection on exfiltration, and JIT-scoped tokens that make Kubernetes lateral movement structurally impossible.

No static secrets means the harvest finds nothing. When services access AWS, GCP, Azure, databases, or APIs through Hush, they receive short-lived, dynamically issued tokens scoped to exactly the permissions the current workload requires. There is no ~/.aws/credentials. No .env file full of API keys. No Kubernetes Secret holding a database password. A malicious package doing a filesystem crawl returns empty-handed, because the material it is looking for does not exist in that form.

Runtime monitoring surfaces the exfiltration attempt. Hush’s runtime sensor uses eBPF to observe system calls without kernel modification or agent overhead. It tracks which processes open which files, which network connections they initiate, and which identities are behind each action. In the litellm scenario, the sensor would have observed: a Python child process (spawned from a .pth handler) opening credential-shaped files across multiple directories, followed immediately by an outbound TLS connection to models.litellm.cloud from a non-human identity with no policy permitting that destination. That sequence generates an alert with full process ancestry, file access trace, and network destination before the POST completes. The security team sees exactly what happened and which workloads were affected, without waiting for a crash report.

Scoped JIT tokens contain lateral movement. Kubernetes service account tokens issued through Hush are scoped to the minimum permissions the workload needs and expire after a short TTL. A token that allows a pod to read its own namespace’s ConfigMaps cannot be used to list secrets across all namespaces or schedule pods in kube-system. The lateral movement stage of this attack requires a cluster-admin-level or broadly scoped service account token to exist as a long-lived credential. With Hush, that token does not exist. The API calls the malware makes return 403, and the attempt is logged.

There is nothing to rotate after the fact. Incident response after a supply chain compromise normally means identifying every secret that was present on every affected machine and rotating all of them across every system that accepted them. That is an enormous operational exercise, it is time-pressured, and it is still reactive: you are closing a window after the theft. With Hush, the tokens that were present when the malware ran were already scoped and short-lived. They expired on their own. The cleanup conversation is about reviewing the runtime alert and confirming no persistent backdoor was installed, not about tracking down which of your 300 service credentials may have been copied.

If you were affected yesterday

If you installed or upgraded litellm on March 24, 2026, treat any machine that ran it as compromised. The immediate steps:

• Confirm the version: run pip show litellm and check for 1.82.7 or 1.82.8 in all environments, virtual environments, and uv caches (find ~/.cache/uv -name "litellm_init.pth")
• Check for persistence: look for ~/.config/sysmon/sysmon.py and ~/.config/systemd/user/sysmon.service on affected machines
• Audit Kubernetes: check kube-system for pods matching node-setup-* and review audit logs for secret enumeration across namespaces
• Rotate all credentials that were present: SSH keys, AWS/GCP/Azure credentials, Kubernetes configs, database passwords, and any API keys in .env files or environment variables

Rotation is necessary. It is also a good moment to ask how many of those secrets needed to be long-lived in the first place, and how many machines they were distributed across. That count is your structural exposure.

The question this attack puts to every engineering team is not “were we hit?” It is “what would our posture look like if a package like this ran on our machines for a week without crashing anything?” If the answer involves rotating hundreds of secrets across dozens of systems after the fact, the architecture itself is the risk.

We built Hush to make that question less frightening. If you want to see what eliminating static secrets looks like for your stack, we are happy to walk through it.

Hush Security delivers a unified access and governance platform for AI and non-human identities, replacing secrets with verified identities and dynamic, just-in-time access policies. 

AI agents are different from traditional workloads. A scheduled pipeline runs the same query every night. A microservice calls the same API with the same parameters. You can predict what they’ll do and scope their access tightly.

AI agents don’t work that way. They reason, interpret, and decide at runtime. They can be manipulated through prompt injection, take unintended actions from vague prompts, or simply make poor judgment calls. An agent with broad access to your data warehouse isn’t just a workload, it’s an autonomous actor with the ability to surprise you.

This changes the access control equation entirely.

Workload Identity Isn’t Enough for Agents

The industry has made real progress on workload identity. Service accounts, managed identities, identity federation, and frameworks like SPIFFE have laid the groundwork, and solutions exist to help put them into practice. But even modern workload identity has a gap when it comes to agents.

Workload identity tells you what is making a request. For traditional workloads, that’s usually sufficient. But AI agents act on behalf of different users, processing different prompts, with different intents. The same agent might query a data warehouse for one user’s regional sales data and, moments later, attempt to update a CRM record for another. Worse, it might be tricked into accessing data the prompting user was never meant to see.

Workload identity treats all of these invocations identically. You’re forced to provision access for the broadest possible use case, giving every user the same effective permissions and giving the agent enough rope to cause real damage if it misbehaves.

Effective Access Policies: Scoping Agents by User Context

The solution is what we call an effective access policy: an access decision resolved from the combination of the agent’s verified identity and the authenticated user’s identity claims.

Agent identity establishes the first plane, confirming which agent is making the request through cloud-native identity, SPIFFE attestation, or other mechanisms.

User identity establishes the second. When a user interacts with an agent, their IdP-issued token carries their identity, group memberships, and roles.

Policy resolution evaluates both together, selecting the privilege set that matches the effective identity. The agent’s access dynamically adjusts based on who is driving it.

This means a sales analyst chatting with an agent gets scoped access to their region’s data, even if the agent could reach the entire warehouse. A finance lead using the same agent gets broader access, because their claims justify it. And if the agent is manipulated into an unexpected query, the damage is bound by the current user’s permissions, not the agent’s total capability.

The user’s identity becomes a natural blast radius limiter.

What This Looks Like in Practice

Consider an AI agent that helps teams interact with Snowflake, Salesforce, and internal APIs through natural language:

A regional analyst asks for sales numbers. The agent’s identity is verified, the analyst’s IdP token identifies them as “EMEA-sales-ops.” The effective policy scopes Snowflake access to EMEA data only, even if the agent is tricked into querying global data.

An account executive asks the agent to update a deal. Same agent, but the user’s token carries “sales-AE” claims. The effective policy grants write access to their own Salesforce opportunities, not the full CRM.

Automated pipeline, no user. The same underlying service runs a scheduled job without a user session. The workload-only policy applies, broad access for a known, predictable task.

The agent never implements this logic. The policy engine evaluates both identity planes and provisions the right credentials just in time.

How Hush Security Approaches This

At Hush Security, we’ve built effective access policies into our Unified Access Management platform. The platform uses SPIFFE for workload attestation, which offers the strongest cryptographic foundation for agent identity, especially in multi-cloud environments, and then it validates IdP-issued tokens for user identity. The policy resolves at runtime, and Hush provisions scoped, just-in-time credentials automatically.

The agent gets exactly the access the current user should have, and nothing more.

If this is a problem you’re dealing with, or one you see coming – we’d love to show you how it works.

How AI-powered security is solving yesterday’s problem while tomorrow’s is already here.

When Anthropic announced Claude Code’s security capabilities, the reaction across the industry was immediate and justified. AI that can scan your codebase, identify vulnerabilities, and suggest fixes in real time is a genuine leap forward. For teams that have spent years manually triaging CVEs and chasing injection flaws across sprawling codebases, this feels like the moment the tide finally turns.

And in many ways, it is.

But there’s a question worth sitting with: when AI locks down the code layer, where does the risk go?

The answer is uncomfortable – and mostly ignored.

The Progress Is Real. So Is the Blind Spot.

Let’s give credit where it’s due. Application security has historically been a game of whack-a-mole. Developers ship fast. Vulnerabilities slip through. Security teams scramble to patch, prioritize, and communicate risk to stakeholders who want everything fixed yesterday. Static analysis tools helped, but they were slow, noisy, and required expertise to interpret. Penetration testing was episodic. Bug bounties were reactive.

AI changes the economics of all of this. Continuous, intelligent scanning embedded in the development workflow means vulnerabilities get caught earlier, fixed faster, and with less human overhead. Injection flaws, misconfigurations, dependency risks – the class of problems that have dominated the AppSec conversation for decades are becoming increasingly addressable through automation.

This is meaningful progress. Fewer CVEs reaching production is unambiguously good.

But security doesn’t operate in a vacuum. When you close one door, attackers don’t give up – they find the next one. And right now, while the industry’s attention is concentrated on making code safer, a different attack surface is quietly expanding.

The Attack Surface Is Shifting – Into Identity

Here’s what’s actually happening underneath the surface of the AI-driven development boom.

Every AI agent, every automated pipeline, every microservice, every cloud workload needs to authenticate somewhere. It needs to talk to a database, call an API, read from storage, write to a queue. And to do any of that, it needs credentials.

In most enterprises today, those credentials are static secrets – API keys, service account tokens, long-lived passwords – stored in vaults, hardcoded in repos, or passed around in environment variables across teams and systems. This was already a fragile approach before AI entered the picture. Now, as organizations race to deploy AI agents at scale, the problem is compounding faster than most security teams can track.

Consider what AI-native development actually produces at the infrastructure level:

More services. More integrations. More automated pipelines. More workloads spinning up and down at runtime. Each one requiring access. Each one representing a potential identity that needs to be managed, monitored, and governed.

The code is getting cleaner. The identity layer is getting messier.

Three Shifts Nobody Is Talking About Loudly Enough

From CVEs to credentials. The vulnerability classes that have dominated security discourse for years – SQL injection, XSS, buffer overflows – are precisely the things AI is best positioned to catch. But the credentials that authenticate the services running that cleaner code? Those are largely outside the scope of AppSec tooling. A perfectly patched application running on an over-privileged service account with a two-year-old API key is still a serious risk. The surface has shifted, not shrunk.

From human to non-human identity. For most of security’s history, identity meant users. You managed employees, contractors, admins. You enforced MFA, monitored login anomalies, revoked access when people left. That paradigm is breaking down. In modern cloud environments, non-human identities – service accounts, machine tokens, OAuth credentials, AI agents – already outnumber human users by orders of magnitude in most organizations. And they’re growing faster. Every new AI agent means dozens(!) of new identities. Every new integration is a new credential. The attack surface is predominantly non-human, and most security architectures were built for a world where it wasn’t.

From static to dynamic. Traditional secrets management was built on a simple assumption: store the credential securely, rotate it periodically, and you’ve done your job. That model made sense when environments were relatively stable. It doesn’t make sense in a world of ephemeral workloads, containerized microservices, and AI agents that spin up, complete a task, and disappear within minutes. A static secret issued to a workload that lives for 30 seconds doesn’t need to be valid for 90 days. But in most organizations, it is – because the infrastructure to do anything different doesn’t exist.

Why the Vault and Scanners are Not Enough

Secrets managers have been the industry default for non-human identity management for good reason. They’re better than hardcoded credentials. They provide centralized storage, access controls, and rotation capabilities. For a long time, they were enough.

But the enterprise environment has outgrown them in ways that are now impossible to ignore.

Vaults are excellent at storing secrets. They’re not designed to answer the questions that matter most in a dynamic, AI-driven environment:

• Where is this credential actually being used?
• Which workload is consuming it right now?
• Is it scoped to the minimum permissions needed for this specific task?
• Has it been sitting dormant for six months because the service it was created for was deprecated and no one noticed?

Discovery tooling has emerged to fill part of this gap – scanning environments for unmanaged credentials, mapping blast radius, surfacing hardcoded secrets in codebases. These tools are valuable. But they’re diagnostic, not prescriptive. They tell you what the mess looks like. They don’t fix it, and they don’t prevent the next one.

The “secretless” architecture vision attempts to eliminate the problem at the root – replacing credentials entirely with identity-based access that doesn’t require a secret to be stored or transmitted. It’s the right destination. But it requires deep re-architecture, significant investment, and migration timelines that most enterprises – especially those in heavily regulated industries with complex legacy environments – simply can’t absorb all at once.

Which leaves most organizations caught between approaches, piecing together a vault, a discovery tool, and some governance layer, and hoping the combination is sufficient.

It usually isn’t.

What the Agentic Era Actually Demands

The deployment of AI agents isn’t a future scenario. It’s happening now, in production, at Fortune 500 companies across every industry. And the security implications are arriving faster than the frameworks to address them.

An AI agent is, from an identity and access perspective, a workload like any other – except it tends to require broader access, operate more autonomously, and interact with more systems than a traditional service. It might need to read from a database, call external APIs, write to a content management system, trigger downstream workflows, and authenticate to multiple internal services, all within a single task execution.

If that agent is operating with a long-lived credential scoped with more permissions than it needs – which is the current reality in most organizations – the blast radius of a compromise isn’t just the agent itself. It’s every system the agent’s credentials can reach.

This isn’t hypothetical. The attack patterns are already emerging. Credential theft targeting automated pipelines. Privilege escalation through over-permissioned service accounts. Lateral movement through interconnected AI workflows. The techniques aren’t new. The scale and speed at which they can be executed against a fragmented, poorly governed non-human identity landscape is.

What the agentic era demands isn’t a better vault or a smarter scanner. It demands a fundamental rethinking of how access is granted, governed, and revoked for non-human identities at runtime.

Specifically, it demands just-in-time access – where credentials are issued for the duration of a specific task, scoped to the minimum permissions required, and automatically revoked when the task completes. No long-lived tokens. No standing privileges. No credentials that outlive the workload they were created for.

It demands unified visibility – a single control plane that spans cloud, hybrid, and on-premise environments, giving security teams a real-time view of every non-human identity, what it has access to, and what it’s actually doing.

And it demands a path that works now – not after a multi-year re-architecture project. Organizations need to be able to reduce risk against their existing infrastructure while building toward a least-privilege, identity-based future. These goals aren’t mutually exclusive, but achieving both requires a platform designed with that tension in mind.

The Winners Will Own the Control Plane

The non-human identity market is crowded and consolidating fast. Vault vendors are expanding their feature sets. Discovery tools are adding governance layers. AppSec platforms are moving into runtime. Everyone is racing toward the middle.

The vendors who win this space won’t be the ones with the best scanner or the smartest vault. They’ll be the ones who unify discovery, storage, and governance into a single control plane – replacing static secrets with just-in-time, identity-based access, across cloud, hybrid, and the legacy systems everyone knows exist but no one wants to talk about.

That’s not a minor product improvement. It’s a different architectural thesis. And the enterprises that figure this out early – that start treating non-human identity with the same rigor they’ve applied to application security – will be the ones operating from a position of strength as the agentic era matures.

The Target Hasn’t Disappeared

AI-powered application security is a genuine advancement. The code layer is getting safer. CVEs are getting caught earlier. Injection flaws that have plagued development teams for decades are increasingly solvable through automation.

But the attack surface hasn’t shrunk. It’s shifted – into workload identity and runtime access. Into the credentials authenticating the AI agents, microservices, and automated pipelines that now form the operational backbone of modern enterprises.

Less vulnerable code. More long-lived credentials. Fewer injection flaws. More over-privileged service accounts. Better applications. More unmonitored AI agents with unchecked access.

The security architecture that got us here was built for a world of human users, monolithic applications, and static environments. It’s not the architecture we need for a world of AI agents, ephemeral workloads, and dynamic, multi-cloud infrastructure.

The shift is already happening. The question is whether security teams will recognize where the new perimeter actually is – and build toward it – before the attackers make it impossible to ignore.