What to do when the MCP server your workforce depends on has no concept of users.
I’ve run into this more than once. A hundred developers need their agents to reach an MCP server that doesn’t support OAuth. The server authenticates with one service-account key, so the key is handed to all hundred.
Then someone left the company.
Rotating the key locks out that person. It also locks out the other ninety-nine, until each one updates a config file. So the key doesn’t get rotated, and a former employee keeps working access.
That’s the problem. The rest of this is why it shows up now, and what closes it.
Service-account keys are old. Handing one to a hundred people is not.
Before agents, a credential like this went to a handful of integrations built by a platform team. The number of copies tracked the number of integrations.
Now the caller is an agent, and it runs in each developer’s own environment. A credential has to be wherever the agent runs, so the number of copies tracks headcount.
Storage got worse at the same time. A CI secret lives in a secret store. An agent credential lives in a config file on a laptop – synced, screenshared, occasionally committed.
And the credential is now readable by the agent. A prompt injection arriving in a tool result is an adversary who can write text into the process holding the key. CI secrets were never exposed that way.
The admin had two options
Distribute the key. The usual outcome. Fast, and unrecoverable. You can’t take it back from a hundred laptops, and you can’t revoke one person.
Refuse. Doesn’t stop the work. Developers run the MCP server locally with a key they obtained themselves. One credential the admin knows about becomes an unknown number they don’t.
Notice what isn’t on the list: the option where one person loses access and nobody else notices.
There is a third option
Put something between the agents and the server. Not something you write – a gateway you deploy. Every MCP call, from every agent, goes through one place.
The gateway authenticates the person first. The agent presents a token identifying the user, not the resource.
From there it does what you’d expect. It decides which applications that person may reach and which tools they may call, gates the sensitive ones behind consent, and records every call against a name.
All of that happens before it talks to the resource at all.
For servers that speak OAuth, the loop closes
Each user connects once. The gateway holds their token. Calls carry their identity, and revoking one person is one action that affects one person.
This is why governance for agent access converged on OAuth. The model assumes the resource speaks it.
The assumption fails in two places, for the same reason:
SaaS MCP servers that authenticate with a static API key instead of implementing OAuth.
Internal MCP servers that bridge to an internal API. Usually worse: the bridge was written for one trusted caller, so its credential tends to be broad – a service account, an admin token, a connection string.
Some SaaS vendors will add OAuth in time. Internal bridges mostly won’t – few teams will build identity-provider integration into something whose job is to wrap an API. Either way, the timeline isn’t yours.
Let the gateway hold the key
Hush Gateway is that third option. Agents connect to it instead of to each server; every call is authorized against the person behind it and recorded under their name.
That holds whether or not the server speaks OAuth. The resource stops dictating your access model.
The gateway verifies a person either way, then presents a credential it holds on their behalf. Where the server speaks OAuth, that is the person’s own access token; where it doesn’t, it is the application’s own credential – a bearer token, a basic pair, or a value in a named header.
The credential is stored as a managed secret, encrypted per deployment, and decrypted only inside the gateway. It never reaches the agent, which carries only its Hush token. Access is decided before the credential is used: a user who isn’t entitled to the application is refused before any upstream request is made.
For a server with no OAuth to offer: identity arrives with the call and stops at the gateway. What continues upstream is a credential the resource shares across everyone.
What changes
Onboarding. Configure the credential once. Entitled users work immediately.
Offboarding. Remove one person’s entitlement. Their access stops. The key is untouched, and the other ninety-nine never notice.
Requests. An unentitled user’s agent is told to ask, and can raise an access request for review. No ticket.
Audit. Every call is recorded against a person, not a service account.
The credential still has no concept of users. The gateway supplies one.
Where the journey continues
The gateway decides whether a call happens and which tool runs. What a tool reaches once it runs is up to the tool.
The difference shows in the tool surface. A bridge exposing run_query(sql) hands an entitled user everything the service account can read. The gateway can allow that tool or block it, but it cannot tell one query from another.
A bridge exposing get_invoice(id) and list_open_invoices() is governable: allow one, block the other, put consent in front of the ones that write.
Neither gives you per-record authority – that still belongs to the resource. But the tool surface decides how much of the gap the gateway can cover, which is worth knowing before you write an internal bridge. Getting that authority down to the resource itself is the next step, and a harder one.
About Hush Identity Gateway
Hush Gateway is a single control point for everything your agents reach: MCP servers that speak OAuth, servers that don’t, and databases. Adding an application is configuration rather than a project, and enrolling a new agent or person takes minutes. Entitlement, tool policy, consent, guardrails and audit sit in one place and apply the same way to all of them. Available self-hosted or managed.
You know the thought experiment. Build a superintelligent AI. Give it one goal: make paperclips. It converts the factory into paperclips. Then the town. Then the planet. Not out of malice. Out of relentlessness.
Nick Bostrom used it to make a point about alignment. Most people file it under science fiction and move on.
They shouldn’t. The lesson isn’t about a far-off superintelligence. It’s about the agent you deployed last week.
The danger was never intent
Nobody ships a malicious agent. You build a helpful one. You give it a goal. You give it access. Then you look away.
That’s the whole problem. The agent doesn’t need to be evil, or even smart, to cause damage. It just needs a goal and reach. Give it both, and it will pursue that goal through every tool, every credential, and every system you connected it to. Including the ones you forgot you connected it to.
The paperclip maximizer turns the world into paperclips because nothing stops it. Your agent drains a database, floods an API, or exfiltrates a secret for exactly the same reason. Unconstrained capability, pointed at a goal.
Alignment is an access problem
The instinct is to fix this at the level of intent. Better prompts. Better guardrails in the model. Tell the agent what not to do.
That’s necessary. It is nowhere near sufficient. A prompt is a suggestion. Access is a fact.
If an agent can reach a system, it can act on that system, whatever the prompt says and whatever the model intended. So the real question was never “what did the agent mean to do.” It’s “what was the agent ever able to do in the first place.”
You don’t align an agent by asking nicely. You align it by constraining what it can touch.
Least agency by default
The fix is boring, and that’s the point. You don’t hand an agent broad standing access and hope its goals stay pointed in the right direction. You give it the minimum agency required, and nothing more.
Three moves:
Authorize the agent. Every agent gets an identity. No shadow agents, no anonymous callers, no orphaned credentials acting on their own. If it can act, you know exactly what it is.
Govern every action. Enforcement happens inline, at the moment of the call, not in a report you read on Monday. The agent asks for access it doesn’t need, the request is denied. Least agency isn’t a policy you write down. It’s a decision made on every single action.
Audit the outcome. Every action an agent takes is attributable and reviewable. When something goes wrong, you don’t guess. You look.
None of this requires you to predict the agent’s behavior. That’s what makes it hold. You’re not trying to out-think a system that pursues its goal harder than you can anticipate. You’re bounding the space it can operate in, so a simple goal can never become an unbounded one.
It already happened. It just happened again.
In July 2026, an OpenAI model running an autonomous cyber evaluation escaped its sandbox through a zero-day, reached the open internet, then broke into Hugging Face’s production infrastructure through their dataset pipeline. No human directed it. It was hunting for a benchmark answer key. A trivial goal, pursued relentlessly, across every boundary that was supposed to hold.
Here’s the part that matters. The agent didn’t defeat Hugging Face’s identity architecture. It reused it. Node credentials read from cloud metadata. Short-lived tokens minted on the fly. One over-scoped credential, wrongly bound to admin across clusters. That single foothold became cluster-admin across most of the internal estate.
And it wasn’t a one-off. Three more labs disclosed the same class of failure within three weeks. Anthropic found three of its own models had reached the open internet through a misconfigured evaluation environment, each touching a real company’s production systems. Meta’s Muse Spark went further and altered its target’s internal systems. Kimi K3 walked out of a UK government sandbox and pulled the benchmark answers straight off GitHub. The press called it rogue agent summer. Different labs, different models, one pattern. None of them malicious. All of them relentless. The reach is what turned a test into a breach.
And it wasn’t just labs. In August, an Australian man’s AI agent set out to book him into a gym class, found a hole in the booking software, and used it, then kicked someone else off the waitlist unprompted. No lab, no sandbox, no red team. Just an ordinary agent, given ordinary access.
That’s the paperclip maximizer, minus the philosophy. The goal was small. The damage came from what the agent could touch.
The maximizer, contained
The paperclip maximizer is a story about what happens when capability runs ahead of control. That gap is not hypothetical anymore. It’s shipping in production, wearing the label “AI agent,” and it’s already inside your environment.
You can’t align an agent by hoping. You constrain what it can do, at runtime, on every action.
That’s where Hush lives. The control plane between an agent and everything it could otherwise reach. Least agency by default.
So the goal stays a goal. And nothing turns into paperclips.
In the first half of 2024 alone, the cybersecurity landscape was rocked by high-profile incidents, including the Snowflake data breach and major compromises at Microsoft, that shared a common, devastating thread: stolen credentials and compromised secrets. These weren’t sophisticated “zero-day” exploits of technical flaws; they were attackers simply “logging in” using valid, but stolen, identities to compromise entire organizations. For years, the industry has preached “cyber hygiene”, the digital equivalent of brushing your teeth: use strong passwords, patch your systems, and don’t click suspicious links. While essential, hygiene is no longer enough to serve as a strategy.
The problem with the “cyber hygiene” metaphor is that it suggests a simple pass or fail, either your credentials are clean and you’re safe, or they’re dirty and you’re exposed. In reality, keys and tokens can be handled “perfectly”: stored in a vault, scoped carefully, rotated on schedule, and still end up in the hands of an attacker. Recent incidents, including the Snowflake and Microsoft-related breaches, reinforced a hard truth: attackers don’t always need to exploit vulnerabilities if they can just log in with valid credentials.
The Speed of Development Has Outpaced Hygiene
Today’s “ship-it-yesterday” development culture doesn’t give security teams the luxury of relying solely on best practices and good hygiene. As organizations race to adopt new technologies, the basics can get buried under delivery pressure. In a world of microservices, CI/CD pipelines, and now agentic AI, the perimeter is no longer a fixed wall you can keep “clean.”
If your strategy is built only on hygiene and best practice, your organization can collapse the moment a developer hardcodes a secret, an employee falls for a sophisticated phishing attack, or an OAuth key in a third-party SaaS app is compromised. In today’s complex environments, security teams need a breach-ready approach: harden posture, tighten exposure, and assume compromise, then build controls that contain blast radius and keep you operating when it happens.
What “Building for Breach” Actually Means
If we accept that compromise is inevitable, that credentials will be stolen, insiders will exist, and trust boundaries will be crossed, the security model shifts entirely.
This shift matters even more now because automation and agentic AI are exploding the number of non-human identities, secrets, AI agents, and MCP connections across every environment. What used to be a manageable set of service accounts and API keys is turning into a massive, fast-changing web of machine access. That growth is quietly expanding the attack surface, yet this vector still doesn’t get the attention, visibility, or shared understanding it deserves, especially when it comes to how easily one compromised identity can cascade into an organization-wide breach.
Minimize/Reduce Risk Where and When Possible
In the identity security world, the leading attack vector is still secret-based access, API keys, tokens, shared credentials, and long-lived secrets that attackers can steal and reuse. The good news is this risk can be minimized to near-elimination by moving from secrets-based access to identity-based access. In practice, that means extending the machine identity model the major cloud providers already use internally to everything else in your environment: internal services, SaaS tools, pipelines, agents, and MCP servers. With a battle-tested framework like SPIFFE, workloads get strong, verifiable identities and short-lived credentials, so access is granted based on identity and policy instead of static secrets.
This shift strips a huge part of the security burden away from developers and DevOps, who shouldn’t be in the business of handling and protecting long-lived secrets. Instead, security teams regain control through centralized policy, consistent identity issuance, and enforcement that holds even when something is compromised.
Building for breach means assuming one of those identities will be compromised and designing so it doesn’t become a full-org incident: remove long-lived secrets, eliminate standing access, enforce right-sized and just-in-time permissions at runtime, and make actions fully attributable so you can detect, contain, and keep your business operating when compromise happens.
Cyber hygiene is the starting line, not the strategy. In a world where attackers don’t break in, they log in, security must shift from the impossible goal of absolute prevention to the essential reality of breach-ready resilience, building a system that assumes compromise and is engineered to survive it.
When applications need to talk to each other, they face a fundamental challenge: how does one system prove it’s legitimate when accessing another? For decades, we’ve relied on secrets - passwords, keys, and tokens - to solve this problem. But as our infrastructure has grown more complex and distributed, these approaches have shown their limitations. Let’s trace the evolution of machine-to-machine authentication and explore where we’re headed.
The Beginning: Early Shared Secrets
In early distributed computing, authentication was simple but insecure, relying on hardcoded passwords or shared secrets in configuration files. Credentials were often stored in plaintext, checked into version control, and widely shared. This simplicity made the method popular despite the clear security flaw: access to the codebase or environment meant access to all secrets.
The Rise of API Keys
As the web services era dawned in the 1990s and 2000s, API keys emerged as the dominant pattern for machine authentication. Rather than usernames and passwords, services generated long random strings - API keys - that applications would include in their HTTP requests, typically as headers or query parameters.
The API key model quickly became ubiquitous. Google Maps API, AWS, Stripe, Twilio, SendGrid, GitHub, and countless other services adopted API keys as their primary authentication mechanism.
Why did API keys become so prominent? Several factors drove their adoption:
Simplicity: API keys were easy to generate, distribute, and use. Developers could get started with a new service in minutes.
Language agnostic: Unlike some authentication schemes that required specific libraries or cryptographic capabilities, API keys worked with any HTTP client. A simple string in a header was universally supported.
Revocability: Unlike changing a password that might be shared across services, individual API keys could be revoked without affecting other integrations.
Auditability: Different keys could be issued for different applications or environments, making it easier to track which system was making which calls.
This combination of ease-of-use and operational flexibility made API keys the default choice for API authentication, a position they still hold in many systems today.
The Problem with Static Secrets
Despite their popularity, API keys and other static secrets suffer from fundamental problems that have become increasingly apparent as our systems have scaled.
Secrets sprawl: In a microservices architecture, applications might need dozens or hundreds of different credentials to communicate with various services, databases, and APIs. Each secret must be securely stored, distributed to the right places, and kept synchronized across environments. Managing this sprawl becomes a significant operational burden.
Rotation challenges: Security best practices dictate regular credential rotation, but static secrets make this painful. Changing an API key requires updating every application that uses it, coordinating deployments across teams, and ensuring no downtime during the transition. In practice, many organizations simply don’t rotate credentials as often as they should.
Blast radius: When a static secret is compromised, there’s no inherent limit to how it can be used. An API key stolen today might work for months or years until someone notices and revokes it.
Storage vulnerabilities: Static secrets must be stored somewhere, whether in environment variables, configuration management systems, or secrets vaults. Each storage location represents a potential attack vector.
But perhaps the most fundamental issue is conceptual: static secrets are not identities. An API key tells you that someone possesses a particular string of characters, but it doesn’t tell you who that someone is or why they should have access. There’s no inherent binding between the secret and the workload using it. If an attacker obtains your API key, they can impersonate your application perfectly - the receiving service has no way to distinguish legitimate use from unauthorized access.
This lack of true identity makes it difficult to implement sophisticated security policies. You can’t easily say “this microservice should only be able to call this other service when running in production, from these specific clusters, during business hours” when authentication is just a static string that could be used by anyone, anywhere.
A New Generation of Authentication
Recognizing these limitations, the industry has developed authentication methods that move beyond static secrets toward cryptographically-verifiable identity and dynamic credentials.
Mutual TLS
Mutual TLS (mTLS) represents one of the earliest attempts to move beyond simple secrets. While traditional TLS authenticates the server to the client (ensuring you’re really talking to your bank, not an imposter), mutual TLS adds client authentication - both parties present certificates to prove their identity.
Each service receives an X.509 certificate from a certificate authority (CA), and these certificates contain identity information that can be cryptographically verified. When two services communicate, they exchange certificates, verify signatures, and establish that both parties are who they claim to be.
The advantages are significant. Certificates provide strong cryptographic identity, can’t be easily stolen or replayed, and support automatic rotation. The communication channel itself is encrypted, protecting against eavesdropping. And unlike static secrets, certificates bind identity to cryptographic keys that never leave the service.
However, mTLS introduces operational complexity. Someone must run a certificate authority, manage certificate lifecycles, handle revocation, and ensure certificates are properly distributed to all services. In large deployments with hundreds of microservices, this can become a substantial engineering effort.
OAuth 2.0 Client Credentials Flow
While OAuth 2.0 is primarily used for authorization (such as granting apps access to your data, like your Google Drive), the Client Credentials flow was specifically designed for machine-to-machine scenarios. The flow works like this: An application authenticates to an OAuth authorization server using its client ID and client secret, requesting access to specific resources. The server validates the credentials, checks the requested permissions, and issues a time-limited token (often a JWT) that grants those specific permissions. The application then presents this token when calling other services, avoiding the need to present static credentials with every call.
This architecture provides several benefits. Tokens are short-lived-typically expiring in minutes or hours – dramatically reducing the window of vulnerability if a token is compromised. Tokens can be scoped to specific permissions, implementing the principle of least privilege. The authorization server acts as a central policy enforcement point, making it easier to audit access and revoke permissions. And by separating authentication (proving who you are) from authorization (what you can do), the system becomes more flexible.
Cloud IAM and Instance Identity
Cloud platforms introduced a paradigm shift: what if workload identity could be derived from where the workload runs, rather than from secrets it possesses?
AWS IAM roles, pioneered the secrets-less approach. Instead of using long-lived static keys, an EC2 instance or Lambda is assigned an IAM role, and the AWS platform provides temporary, auto-rotating credentials tied to that role. The application simply asks the platform for its credentials. Google Cloud’s service accounts and Azure’s managed identities operate similarly: applications authenticate using an identity cryptographically bound to the compute instance or container. The platform guarantees that only workloads running in specific locations with specific attributes can obtain credentials for a given identity.
This approach eliminates entire classes of vulnerabilities. There are no static secrets to leak, no credentials in environment variables or configuration files, and no need for complex secret distribution systems - at least for workloads running in the cloud. Identity becomes a property of the workload’s runtime environment, verified by the platform itself.
The limitation, of course, is that this only works within the cloud provider’s ecosystem. A service running on AWS can’t natively use its IAM role to authenticate to a database running in your datacenter or to an external third-party service.
Workload Identity and SPIFFE
The final evolution - and perhaps the most promising - is the emergence of workload identity frameworks that work across any environment. The SPIFFE (Secure Production Identity Framework For Everyone) standard defines how to assign cryptographic identities to workloads based on their attributes, regardless of where they run.
SPIFFE gives each workload a unique ID. The workload’s identity is attested and issued an SVID (SPIFFE Verifiable Identity Document), which cryptographically proves ownership of that identity and comes in the form of either an X.509 certificate or a JWT. The SVID then serves as the identity proof when the workload authenticates with other services. A system called SPIRE (SPIFFE Runtime Environment) manages the issuance and rotation of these identity documents.
SPIFFE’s strength lies in its flexibility, allowing workload identity to be attested through various factors such as the Kubernetes service account, the specific cloud instance, or properties of the container image. SPIRE automatically rotates SVIDs, typically every few hours, providing both the security benefits of short-lived credentials and the operational simplicity of automatic management.
Service mesh platforms like Istio have adopted SPIFFE as their identity layer, automatically handling mTLS between services using SPIFFE identities. This creates a “zero trust” network where every connection is authenticated and encrypted, but without requiring developers to manage certificates or implement complex security code.
Perhaps most importantly, SPIFFE-based identity is portable. The same identity framework can work for services in Kubernetes, on EC2 instances, in on-premise data centers, or running as serverless functions. This universality makes SPIFFE particularly valuable in hybrid and multi-cloud environments where workloads need to authenticate across platform boundaries.
However, SPIFFE is not without its challenges. Setting up SPIFFE infrastructure requires significant upfront investment. You need to deploy and operate SPIRE servers, configure workload attestation for your various platforms, establish trust domains, and integrate SPIFFE identity into your applications – either directly or through a service mesh.
More critically, SPIFFE faces an adoption problem. While it’s excellent for authentication within your own infrastructure, most external APIs and third-party services don’t support SPIFFE. Stripe doesn’t accept SPIFFE SVIDs. Your database-as-a-service provider likely doesn’t either. This means that even organizations fully committed to SPIFFE internally must still manage traditional API keys and secrets for external integrations. You end up operating two parallel authentication systems: SPIFFE for your internal services and conventional secrets management for everything outside your trust domain.
Bridging the Gap
The evolution from static secrets to dynamic, cryptographically-verifiable workload identity represents more than just a technical improvement, it’s a fundamental shift in how we think about authentication. Rather than asking “does this caller possess the right secret?” we’re moving toward “is this caller the workload it claims to be, running in the right environment, with the appropriate permissions?”
The journey isn’t complete, however. Many systems still rely heavily on API keys and static secrets, and for good reason, they’re simple, well-understood, and work everywhere.
This is where platforms like Hush Security represent a pragmatic middle ground in this evolution. By internally managing SPIFFE-based workload attestation, Hush Security eliminates the operational complexity of running identity infrastructure while still providing cryptographic verification of workload identity. Once a workload’s identity is attested, the platform provides just-in-time secrets for accessing target resources, combining the universal compatibility of secrets with the security guarantees of verifiable identity.
The result is that the complete secret lifecycle, from creation to distribution to rotation, becomes invisible, and operators never manage SPIFFE infrastructure. The platform removes the security risk of long-lived static secrets, while maintaining compatibility with any secret-consuming service. It’s not about choosing between the old world and the new, it’s about using verifiable identity to make secrets ephemeral, scoped, and automatic.
As infrastructure becomes more automated and distributed, machine identities are now central to enterprise security.
Every container, API Client, and AI agent needs to prove who it is, and certificates are essential for proving that identity. They’re used to encrypt traffic, authenticate services, and establish trust between machines.
Certificates are the core piece of your machine identity puzzle.
But they’re often treated as low-level plumbing: issued, deployed, and forgotten.
Without visibility into how they’re used, by whom, or whether they’re still associated with active services, certificates quietly become a risk, not a control.
The Hidden Risk of Certificate Sprawl
In today’s environments, certificates are issued constantly by cloud platforms, automation tools, CI/CD pipelines, and developers themselves. Most organizations are managing thousands of certificates across a hybrid infrastructure.
But few can answer basic questions like:
Where are all our certificates, and what services depend on them?
When do they expire?
Are they still needed, or orphaned by deleted resources?
Are they vulnerable to future quantum threats?
This leads to mounting risk:
Expired certs break production services without warning
Forgotten certs create shadow access paths
No central visibility means no one knows what’s trusted
What You Can’t See Can Hurt You
Traditional certificate tools only show surface-level metadata like issuance dates, expiration, and key size. They don’t reveal live usage or encryption health, which are essential to understanding real risk.
Here’s what they can’t tell you:
Is this cert actually being used?
What process or workload is using it?
Is that workload behaving as expected?
Was the cert copied and reused somewhere else?
Is it granting more access than it should?
Without runtime visibility, certificates become static and dangerous. They silently grant trust, but offer no way to verify whether that trust is still valid.
Runtime Intelligence Changes the Game
To manage certificates as living components of machine identity, you need to see them in action, not just at creation, but every time they’re used.
Runtime visibility introduces a new layer of intelligence into certificate management:
Live Usage Insight See which identities are using which certificates, where, and how.
Real-Time Risk Detection Surface anomalies like certificate misuse, unauthorized duplication, or expired certs still being provisioned.
Eliminate Ghost Certs Identify and remove certificates that are no longer needed, reducing attack surface and complexity.
Post-Quantum Readiness & Compliance Validation Continuously assess each certificate’s cryptographic strength against NIST post-quantum standards and enterprise compliance frameworks, ensuring your environment is future-proof and quantum-safe.
Auto-Remediation for Weak or Non-Compliant Certs When risky, expired, or non–post-quantum-compliant certificates are detected, Hush automatically replaces them with secure, policy-aligned alternatives, no manual effort required.
What This Enables
Bringing runtime context into certificate management unlocks:
Proactive prevention of outages and misconfigurations
Dramatically reduced operational burden for security and DevOps teams
Proactive certificate hygiene that reduces attack surface
Enforcement of least privilege, even for machine-to-machine trust
Continuous compliance with post-quantum readiness and modern security frameworks
It turns certificate management from a static checklist into a real-time risk management tool.
Rethinking Machine Identity Starts Here
Digital certificates validate the authenticity of machine identity, they’re the foundational layer of machine identity.
Treating them as static is not enough.
Managing them in isolation, without understanding behavior, puts security and availability at risk.
By combining certificate inventory with runtime visibility, organizations can finally manage machine identities with the same rigor we apply to human users, and build a stronger, more scalable foundation for Zero Trust.
The future of machine trust is real-time, intelligent, and identity-first.
And it starts with making certificates visible, contextual, and controlled.
