Zero Trust for AI Agents: How We're Rethinking Security at Alquimia

Zero trust frameworks were built for infrastructure that doesn't act autonomously; securing AI agents requires extending those principles — verifiable non-human identity, least-privilege authorization, assume-breach design — to cover a new attack surface unique to agents: manipulated language, autonomous decision-making, and shared-process identity.

01The problem with trusting anything by default

Traditional security models work like a building with a guarded front door: once you're inside, you're mostly trusted to move around freely. Zero trust throws that model out. Every request, every action, every internal call has to prove itself — continuously, not just once at the door.

That's already a meaningful shift for traditional software. But Alquimia isn't traditional software — it's a platform where autonomous AI agents plan, retrieve information, call tools, and take actions with real side effects, often without a human watching every step. That changes the security question entirely. It's no longer just "who's allowed in." It becomes: which agent is this, what is it allowed to do right now, and how do we know its next action isn't the result of someone tricking it?

That last question barely exists in traditional zero trust literature. It's central to ours.

02A new kind of identity to secure: the non-human kind

Security teams have spent decades getting good at managing human identity — logins, passwords, MFA, single sign-on. But the fastest-growing population of "identities" in any modern system isn't human at all. It's service accounts, API keys, containers, scripts, and now, autonomous agents — all making requests, calling APIs, and touching data on their own. This is often called the non-human identity (NHI) problem, and it's one of the areas security is racing to catch up on, because these identities typically outnumber human users by a wide margin and are frequently the least scrutinized part of a system.

AI agents push this problem further than a typical service account ever did. A service account usually does one predictable thing. An agent can plan, chain tool calls together, and take actions that weren't explicitly scripted in advance — which means it needs everything a human identity would get (a verifiable identity, scoped permissions, credentials that expire) plus controls for the fact that its next move isn't fully predictable ahead of time. Treating our agents as first-class non-human identities — not an afterthought bolted onto infrastructure security — is one of the core design decisions behind everything described below.

03Every agent gets a verifiable identity — even when they share a pod

The foundation of zero trust is knowing, with cryptographic certainty, who's making a request. For most systems, that means "which server" or "which service." For Alquimia, it means something more granular: which specific agent, running as one of potentially many concurrent tasks inside a shared pod, is asking to do something.

We built this on SPIFFE and SPIRE, an open standard for workload identity that's normally used to identify one process per credential. Our agents don't fit that mold — several can be active at once inside the same pod, working on different tasks simultaneously. So we extended the model: each agent role gets its own verifiable identity, issued dynamically, independent of which physical process it happens to be running in at that moment.

The practical effect: a compromised or misbehaving component can't simply "borrow" the trust of a different agent. Every agent's identity is real, distinct, and checked — not assumed.

04Identity isn't the same as permission

Here's something we think a lot of "zero trust for AI" conversations get wrong: proving who an agent is doesn't tell you what it should be allowed to do right now.

An agent might have a perfectly valid identity and still be attempting something it shouldn't — reading data outside its scope, calling a tool it has no business calling, taking a destructive action based on a manipulated instruction. So we treat authorization as its own layer, separate from identity entirely:

• Agents can only use tools and data sources pulled from a curated, verified registry — nothing ad hoc, nothing unvetted.
• Every tool call is checked against what that specific agent role is actually permitted to do — a valid identity does not equal a blank check.
• Actions with real consequences — deletions, external writes, anything hard to undo — go through a human approval step rather than executing autonomously.

That last point matters more than it might sound. Most zero trust frameworks were designed for infrastructure that doesn't decide things. Ours does. So we added the equivalent of a checkpoint for consequential decisions, not just for network access.

05Guarding the two ends of every conversation

Large language models introduce an attack surface that didn't really exist before: language itself. A malicious or cleverly-worded input can attempt to hijack an agent's instructions (prompt injection), and a manipulated or compromised model can attempt to leak internal information, fabricate confident-sounding falsehoods, or output something unsafe for a downstream system to act on.

We guard both ends of that pipe:

• Incoming: user input passes through guardrails designed to catch and neutralize prompt injection attempts before that input ever reaches an agent's working context.
• Outgoing: everything an agent produces is verified and sanitized before it's trusted downstream — closing off system prompt leakage, unsafe outputs being acted on automatically, and sensitive information slipping into a response it shouldn't be in.

We apply the same discipline to what agents retrieve, not just what they generate. Our agents pull knowledge from vector databases, and we restrict that retrieval to a trusted, internally-verified set of knowledge sources — an agent can't be pointed at arbitrary or poisoned data and treat it as ground truth.

06Secrets that are never sitting around waiting to be stolen

Every real system needs credentials — API keys, database passwords, tokens. The zero trust principle here is simple to state and hard to get fully right: nothing should be long-lived, and nothing should have more access than it strictly needs.

We manage all of this through Vault, with a few deliberate choices:

• Credentials rotate automatically rather than sitting static for months.
• Every credential is scoped to the specific agent that needs it — there is no master key that unlocks everything.
• Where possible, credentials are generated on demand for a single use and expire automatically, rather than being a long-lived secret that just gets rotated periodically.

The underlying idea: even in the event something goes wrong, whatever a compromised component could get its hands on should be as narrow and short-lived as possible.

07Designing as if the attacker is already inside

There's a principle that sits underneath all of this, and it's worth naming directly: assume breach. Instead of designing defenses around the hope that attackers stay outside the perimeter, we design as if one already got in — a credential is already stolen, a component is already compromised, an agent has already been manipulated into doing something it shouldn't. The question stops being "how do we keep them out" and becomes "if they're already in, how little can they actually do, and how fast do we know about it."

That mindset is what ties every layer above together. It's why no single agent or credential can unlock everything. It's why permissions are scoped as narrowly as possible instead of broadly for convenience. It's why consequential actions need a human checkpoint instead of running unattended. Each of those decisions makes sense on its own, but they add up to something bigger: even in a worst-case scenario, the blast radius stays small and contained rather than turning into free run of the system.

And because no design, however careful, eliminates risk entirely, we pair that containment with the ability to reconstruct exactly what happened afterward. Encryption and auditability run through the whole platform, not bolted on at the edges — conversation data, operational logs, and internal agent configuration are all encrypted at rest, and every significant action leaves a signed, traceable record. If something ever needs investigating, we're not left guessing.

08Why this matters beyond Alquimia

Most zero trust guidance today was written for infrastructure — servers, containers, networks. Very little of it grapples with systems that act autonomously, interpret natural language, and make consequential decisions on their own. We think that gap is going to matter a lot more over the next few years, as more platforms give AI agents real authority to act rather than just answer questions.

Our approach isn't a finished product — it's an evolving architecture, and we expect it to keep changing as we learn more about how these systems actually fail in practice. But the core principle stays fixed: verify continuously, trust nothing by default, and design every layer as if something will eventually try to break it — because in a system where autonomous agents are taking real actions, that's not paranoia. It's just accurate.