CogniContext
All Posts
# Zero-Trust for AI Agents: Why Your API Keys Are a Liability *Published by the CogniContext Team · June 2025* --- There's a credential sitting in a `.env` file somewhere in your organization right now that has write access to your production database. It was created three years ago for an internal tool that was deprecated eighteen months ago. Nobody knows who created it. The tool is gone, but the credential still works. This is not a hypothetical. According to GitGuardian's 2024 State of Secrets Sprawl report, the average enterprise has thousands of active credentials embedded in code repositories, CI/CD systems, container images, and configuration files — many of them long orphaned. The percentage of organizations that have comprehensive visibility into their credential sprawl is close to zero. Now consider what happens when AI agents enter this environment. --- ## The New Attack Surface AI agents are different from conventional software in ways that matter deeply for security. Conventional software executes deterministic logic: given input X, perform operation Y. The blast radius of a compromised conventional service is bounded by what that service was designed to do. If an attacker compromises your read-only analytics API, they can read analytics data. They generally can't pivot from there unless they find additional vulnerabilities. AI agents execute probabilistic, compositional reasoning. They chain tool calls. They make inferences. They take actions based on the contents of documents they retrieve. A single agent session might touch a dozen different systems, combining information across them in ways the original system designers never anticipated. This has two security implications: **1. The attack surface for each agent is the union of every tool and data source it can access.** If your incident-response agent has credentials for PagerDuty, Datadog, AWS CloudWatch, and your internal GitHub organization, an attacker who can influence that agent's behavior — through prompt injection in a retrieved document, a malicious tool response, or a manipulated system prompt — effectively has access to all of those systems through the agent. **2. The blast radius is multiplicative, not additive.** A compromised agent that can read from ten systems and write to three doesn't just expose those thirteen surfaces. It can read from all ten and use that information to craft targeted writes to the three. The attack surfaces compound. This is why the security model that works for conventional software — give each service the credentials it needs, use least privilege where convenient, audit access logs reactively — is not sufficient for AI agents. --- ## Why Current Approaches Fail ### API Keys and Service Accounts The dominant pattern for connecting AI agents to enterprise systems is service account credentials: API keys, personal access tokens, OAuth client secrets. These are embedded in environment variables, passed to agent runtimes at initialization, and stored in secrets managers with varying degrees of rigor. The problems are well understood: **They're static.** A key that works today works in six months if nobody rotates it. Rotation requires coordination. Coordination is friction. Friction means rotation doesn't happen on the schedule it should. **They're coarse-grained.** GitHub personal access tokens have scopes, but those scopes are broad: `repo`, `read:org`, `workflow`. There's no scope for "read only the repositories in this specific team." AWS IAM is more fine-grained, but writing precise least-privilege policies requires expertise and discipline that most organizations apply inconsistently. **They don't carry identity.** When an API key is used, the audit log shows that *something* made the call. It doesn't show which agent, which user's session, which task, or what context led to the call. Forensic investigation is guesswork. **They outlive their purpose.** Service accounts for decommissioned tools keep working. Tokens issued for one agent get copy-pasted to another. The credential lifecycle is completely disconnected from the agent lifecycle. ### VPNs and Network Perimeters The traditional enterprise security model is perimeter-based: build a wall around your internal network, assume everything inside is trusted, control what comes in from outside. This model has been eroding for years under the pressure of cloud adoption, remote work, and SaaS proliferation. For AI agents, it's essentially meaningless. AI agents need to access resources across cloud environments, SaaS platforms, on-prem systems, and external APIs — all simultaneously. There is no perimeter that contains all of these. A VPN gives you a tunnel into one network segment. It doesn't help you govern an agent that needs to access eight different network segments plus three external SaaS APIs in a single task. More fundamentally, perimeter security grants network access, not service access. An agent that's on the corporate VPN can try to reach any service inside the perimeter. The only thing standing between it and your internal systems is whether the service is listening on the network — not whether the agent is authorized to use the service. --- ## Zero-Trust Principles Applied to AI Zero-trust is not a product or a vendor category. It's an architectural principle: **never trust, always verify.** Every access request is evaluated regardless of network location. Access is granted based on identity, not based on being inside a network boundary. Applied to AI agents, zero-trust means: ### Identity Is Continuous, Not Perimeter-Based Every agent has a cryptographic identity that it presents with every request. This identity is separate from the user's identity — it represents the agent itself, the specific instance, the task context. The receiving system verifies this identity before honoring any request. Critically, this identity is verified at every hop, not just at entry. If agent A calls tool B, which needs to access service C, service C verifies the original agent's identity as well as the intermediate service's identity. There are no implicit trust relationships based on network position. ### Least Privilege Is Enforced Dynamically An agent that's running an incident response task gets access to monitoring tools and historical incident data. The same agent framework, running a different task, might get a completely different access set. Permissions are granted per-session and per-task, not per-agent-type. This requires a policy engine that can evaluate "should agent X, running task Y, with user context Z, be allowed to call tool T?" in real time. Static permission lists can't express this. Dynamic policy evaluation can. ### Credentials Are Short-Lived and Bound to Identity Instead of long-lived API keys, agents receive short-lived credentials cryptographically bound to their identity. These credentials expire within the task session. If they're intercepted, they can't be replayed once expired. If an agent is decommissioned, its identity is revoked and all associated credentials immediately become invalid. ### Every Access Is Audited with Full Context The audit record for an access event includes not just what was accessed, but by which agent, in which session, under which user's authority, as part of which task, following what reasoning chain. When something goes wrong, you have the full context needed for forensic investigation, not just a timestamp and a credential ID. --- ## OpenZiti: Software-Defined Zero-Trust Networking The network layer of this model requires a different approach than conventional networking. OpenZiti is an open-source software-defined networking platform that implements zero-trust principles at the network level. It's the same technology that underlies Ziti's commercial offerings and has been deployed in production at significant scale. The core idea is to eliminate exposed network endpoints entirely. Instead of an AI agent connecting to `https://internal-database.company.internal:5432`, there is no such hostname. The database is not addressable from the network at all. It connects outbound to an OpenZiti fabric as a named service: `database.internal.company`. The AI agent, having authenticated to the same fabric with its cryptographic identity, can reach that named service if and only if its identity is authorized for it. The connection between agent and service traverses the fabric, encrypted end-to-end. There is no network path from the agent to the service that bypasses the fabric. There are no firewall rules to maintain, no VPN tunnels to manage, no network ACLs that can drift out of sync with the intention. This model has several properties that matter for enterprise AI: **Multi-cloud transparency.** The database can be on AWS. The agent can be running on GCP. The fabric handles routing. Neither side needs to know where the other is. **On-prem without VPN.** A service running on-premises can be made accessible to cloud-based agents through the fabric without exposing it to the public internet or requiring an IPSec VPN. **Fine-grained service authorization.** Authorization is per named service, not per network segment. You can authorize an agent to access `jira.integrations.company` but not `github.integrations.company`, even though both are internal services on the same network segment. **Auditability.** Every connection attempt is logged with the identities of both parties. Failed authorization attempts — an agent trying to access a service it's not authorized for — are surfaced as security events. --- ## RBAC and Tenant Isolation Zero-trust networking handles the connectivity layer. Role-based access control handles the authorization layer. For enterprise AI, both are necessary. RBAC for AI agents looks different from RBAC for human users in a few ways: **Agents have roles, not just users.** A "junior engineer" role might allow a human to read code repos and create pull requests. The equivalent AI agent role might allow read access to repos, issues, and CI logs, but not the ability to merge or deploy. The agent's role is derived from the human's role but scoped further. **Roles are composable by task.** An agent performing incident response might combine capabilities from "monitoring read" and "runbook execute" roles. An agent performing code review might combine "repo read" and "comment write" roles. Roles should be compositional, not fixed bundles. **Tenant isolation is non-negotiable.** In a multi-tenant enterprise environment — multiple teams, divisions, or business units — an agent authorized for one tenant must have a hard guarantee that it cannot access another tenant's data. This is not "we checked the access control logic," it's a cryptographic guarantee enforced at the network and storage layers. --- ## When to Require Human Approval Zero-trust doesn't mean autonomous. There are categories of AI agent actions that should require explicit human approval before execution, regardless of whether the agent is technically authorized to perform them. A useful framework: **Always require approval for:** - Irreversible destructive actions (database deletes, infrastructure teardown, user account revocation) - Actions that affect multiple tenants or cross organizational boundaries - Actions that exceed a defined "blast radius" threshold (e.g., a single tool call that would touch more than N records) - Actions flagged by the policy engine as anomalous based on historical patterns **Require approval in elevated-risk contexts:** - Outside business hours - From previously-unseen agent versions - Following retrieval of content from untrusted sources (potential prompt injection) - When the confidence of the agent's reasoning falls below a threshold **Allow without approval:** - Read-only operations with bounded scope - Reversible writes within defined parameters - Actions with complete audit trails and automated rollback capability This framework — sometimes called "human-in-the-loop orchestration" — is the difference between AI agents as autonomous actors and AI agents as powerful tools under human oversight. The right answer for most enterprise deployments in 2025 is the latter. --- ## Building a Zero-Trust AI Security Posture: A Practical Starting Point If you're starting from the current state — API keys in `.env` files, VPN-based network access, no agent-specific audit trail — the path to zero-trust doesn't have to be a big-bang migration. **Start with inventory.** You cannot govern what you don't know about. Build a complete picture of which AI agents exist, what credentials they hold, and which systems they touch. This is unglamorous work and often produces uncomfortable findings. **Implement cryptographic identity for new agents.** Don't retrofit existing agents immediately — build new agents with identity-based auth from the start. Each new agent should have its own identity, issued credentials for only what it needs, and an explicit expiration policy. **Move to service-level authorization.** For the systems your agents most commonly access, implement authorization at the service level rather than relying on network position. An API gateway or MCP gateway with authorization logic is the minimal version of this. **Audit first, enforce second.** Before implementing hard policy enforcement, run authorization checks in audit mode — log what would be denied without actually denying it. This surfaces false positives in your policy definitions before they block legitimate agent operations. **Work toward zero-trust networking incrementally.** You don't have to move everything to a zero-trust fabric at once. Start with the highest-risk internal services — production databases, code repositories, credential stores — and work outward. --- ## Conclusion The API key in your `.env` file is not just a credential management problem. It's a symptom of a security model that was designed for conventional software and doesn't account for the compositionality, autonomy, and broad system access of AI agents. Zero-trust — cryptographic identity, dynamic least-privilege access, no implicit network trust, continuous verification, and human-in-the-loop gates for high-stakes operations — is the security architecture AI agents require. This isn't a theoretical future state. The primitives exist today: OpenZiti for zero-trust networking, short-lived token issuance systems for credential management, policy engines for dynamic authorization, audit frameworks for full observability. What's missing in most organizations is the integration layer that brings these primitives together specifically for AI agent workloads. That's the problem CogniContext is built to solve. --- *Next in this series: [Agent Amnesia — Why AI Agents Forget Everything and How to Fix It](./04-persistent-memory-for-ai-agents.html)*