The credential problem nobody talks about
Here’s a dirty secret of the AI agent industry: most agent frameworks give the LLM direct access to API keys, OAuth tokens, and customer credentials. The reasoning is simple — the agent needs to call APIs, so it needs the credentials to do so.
This is catastrophically wrong.
Large language models are probabilistic systems. They can be prompt-injected. They can hallucinate API calls. They can leak context across sessions. Treating an LLM as a trusted component in your security architecture is like giving your intern the root password and hoping for the best.
The forward proxy pattern
shiftagent’s architecture treats the LLM as an untrusted component — always. The agent environment never contains real credentials. Instead, it contains aliases: human-readable references like @merchant_api_key or @stripe_secret that have no value outside the system.
When an agent makes an outbound request, it passes through a forward proxy — the only component in the system that can resolve aliases to real secrets. The proxy:
- Intercepts the outbound request
- Resolves any credential aliases to their real values from the vault
- Forwards the request to the destination
- Strips real credentials from the response before returning it to the agent
The LLM never sees the real values. Not in the request, not in the response, not in the logs.
Why this matters for PCI DSS
Payment Card Industry Data Security Standard (PCI DSS) has strict requirements about where cardholder data can exist and who can access it. If your AI agent has direct access to PANs, API keys, or merchant credentials, your entire agent infrastructure falls into PCI scope.
With the forward proxy pattern, the agent layer is out of PCI scope by architecture. The only component that touches real credentials is the proxy itself — a small, auditable, purpose-built gateway. This reduces your compliance surface from “the entire AI platform” to “one proxy service.”
Defense in depth
The forward proxy is one layer of a multi-layer security architecture:
Vault aliases — Credentials are stored in a vault (HashiCorp Vault, AWS Secrets Manager). The agent environment only contains aliases. Even if an attacker compromises the agent sandbox, they get meaningless strings.
CIBA approval flow — High-risk agent actions trigger a Client Initiated Backchannel Authentication (CIBA) flow. The human operator receives a push notification to approve or deny the action before it executes. No credential is resolved until approval is granted.
Risk classification — Every agent action passes through a rules engine (GORules) that classifies the risk level. Low-risk actions (reading data, generating reports) execute autonomously. Medium-risk actions (sending emails, modifying records) may require approval. High-risk actions (financial transactions, credential rotation) always require human approval.
Tenant security inheritance — Each tier in the multi-tenant hierarchy inherits the security posture of the tier above it. A tenant can tighten security (require approval for more action types) but can never loosen it. If the platform requires approval for financial transactions, no tenant can override that.
The sandbox boundary
Each agent execution runs in an isolated sandbox:
- Network isolation — outbound requests can only go through the forward proxy. Direct internet access is blocked. EC2 metadata endpoints are blocked. Internal network ranges are blocked.
- File system isolation — the agent operates in a temporary workspace. It cannot access other tenants’ data, the host system, or persistent storage outside its designated paths.
- Resource limits — CPU, memory, and execution time are bounded. A runaway agent cannot consume unbounded resources.
- Audit trail — every tool call, every API request, every file operation is logged with the full context chain: which tenant, which user, which conversation, which playbook step.
Building security into the architecture
The fundamental insight is this: security policies are only as strong as their enforcement mechanism. A policy that says “agents should not access credentials directly” is worthless if the architecture makes direct access the path of least resistance.
shiftagent’s architecture makes the secure path the only path. There is no way for the agent to access real credentials because the architecture physically separates the reasoning layer from the credential layer. The forward proxy is not a guardrail you can drive around — it’s the only road.
This is what “zero-trust by architecture” means. Not a checklist of security features bolted onto an existing system. A system designed from the ground up so that trust is never assumed, credentials are never exposed, and every action is auditable.
shiftagent’s zero-trust architecture ensures your AI agents never touch real credentials, every action is risk-classified, and security tightens — never loosens — at every tier of your organization. Want to see how it works under the hood? Get in touch →