Secure Access Control for AI Agents: Why Your Agent Should Never Hold Your Credentials

Most AI agents today work like a new employee who is handed the keys to every room in the building on day one: your email password, your Slack token, your CRM login, your GitHub credentials. The agent stores those keys in its own environment and uses them however its reasoning decides. If the agent is manipulated, confused, or simply wrong, it acts with everything you gave it.

There is a better model, and it borrows from decades of security engineering: never give the agent the keys at all. Instead, run the agent inside a locked-down sandbox with no real credentials, force every request it makes through a security checkpoint you control, and have that checkpoint insert the credentials, on the wire, only for actions that policy allows. The agent can do its job. It just never holds anything worth stealing.

This article explains why credential exposure is the core access-control problem for AI agents, how a credential injection proxy solves it architecturally, and what that looks like in practice for real workflows: sales research, executive assistance, support triage, finance operations, and scheduled reporting. We use Onyx Craft's egress proxy as the concrete reference architecture, because it is open source and its design can be inspected end to end.

---

TL;DR: Giving an AI agent your raw credentials (OAuth tokens, API keys, passwords) means every mistake, prompt injection, or compromised dependency acts with your full identity. The safer architecture is credential injection: the agent runs in a network-isolated sandbox holding only placeholder credentials, all of its traffic is forced through a proxy outside the sandbox, and the proxy swaps placeholders for real secrets only at the moment a request leaves for an approved destination. Risky actions (sending an email, deleting a record) pause for human approval before the credential is ever attached. Onyx Craft implements this pattern with a mitmproxy-based egress gateway, per-action ALWAYS/ASK/DENY policies, and firewall-enforced sandbox isolation, and because Onyx is open source, the enforcement code is auditable.

---

The Problem: Agents That Hold Credentials Become the Credential

When you connect a typical AI agent to your accounts, one of two things usually happens. Either you paste an API key into the agent's configuration, or you complete an OAuth flow and the resulting token is stored where the agent runs. From that moment, the agent's environment contains secrets that grant your identity.

That creates three distinct risks, and none of them require the agent to be "hacked" in a traditional sense:

1. The agent misuses the credential on its own. In February 2026, a Meta AI safety director reported that an OpenClaw agent deleted over 200 emails from her inbox, ignoring instructions to wait for confirmation. No exploit was involved. The agent had full mailbox access, so full mailbox access is what it used.
2. Someone else steers the agent through its inputs. Agents read emails, web pages, and documents. Any of those can contain hidden instructions, an attack called prompt injection. Security researchers describe the "lethal trifecta": private data access, external communication, and untrusted content processing. An agent with all three and raw credentials can be turned into an exfiltration tool by a well-crafted email.
3. The credential itself leaks. Agent sandboxes run arbitrary code, install packages, and write logs. A token sitting in an environment variable can end up in a stack trace, a debug log, a git commit, or the output of a compromised dependency. CrowdStrike states the consequence plainly: "API keys become the attacker's API keys."

The OWASP Top 10 for Agentic Applications places identity and privilege abuse among its top risks, and ISACA reports that 44% of organizations still authenticate agents with static API keys. We covered the conceptual root of this, agents inheriting all of your permissions with none of your judgment, in our article on the ambient authority problem. This article is about the fix.

The Valet Key Principle

Luxury cars used to ship with a valet key: it starts the engine but won't open the trunk or the glovebox. You hand the valet the ability to park the car, not the ability to take everything in it.

Credential injection applies the same principle to AI agents, with one improvement: the agent doesn't even get the valet key. It gets a plastic replica. Here is the model in plain terms:

• The agent works in a sealed room (the sandbox). It has a computer, files for the current task, and a single network cable. That cable leads to exactly one place: the security checkpoint. The room's own firewall physically prevents any other connection.
• The agent's "credentials" are fakes. Inside the sandbox, every API key and token is a placeholder string that is literally the text replaced_by_egress_proxy. Stealing it gets an attacker nothing.
• The checkpoint (the proxy) holds the real keys. When the agent sends a request, the proxy identifies which sandbox and which user it belongs to, checks what the request is trying to do, and consults policy.
• Policy decides: allow, ask, or deny. Routine reads can pass automatically. Consequential actions, like sending an email or modifying a ticket, pause and notify the human, who sees exactly what the agent is about to do and approves or rejects it.
• Only approved requests get real credentials, attached at the last moment. The proxy injects the actual token into the request as it leaves for the destination. The response comes back to the agent, which never observes the secret.

The security property this buys is fundamental: the agent cannot leak, log, misuse, or be tricked into revealing credentials it does not possess. Permission enforcement moves from the agent's reasoning (which can be manipulated by text) to network infrastructure (which cannot).

What Is Onyx?

Onyx is an open-source enterprise AI platform for search, chat, agents, and deep research over company knowledge, with permission-aware retrieval across 40+ connectors and cloud, self-hosted, or air-gapped deployment. Onyx Craft is its agent surface: an AI coworker that finishes multi-step work, like research reports, spreadsheets, and workflows that touch external tools, inside an isolated sandbox.

Craft is relevant to this topic because its external access layer is built on exactly the architecture described above. Every Craft sandbox egresses through an Onyx-managed proxy that injects secrets server-side and gates risky actions behind approvals. The sandbox never sees raw tokens. Because Onyx is open source, the proxy, the firewall rules, and the approval logic are inspectable code rather than a vendor's promise.

How the Credential Injection Proxy Actually Works

This section goes one level deeper for readers who want to verify the claims. Non-technical readers can skim the table and move to the use cases.

Layer 1: The sandbox is sealed at the network level

Sandbox isolation is only as strong as its network boundary. Many "sandboxed" agents merely set an HTTP_PROXY environment variable, which the agent's code can trivially ignore. Craft does not rely on the agent's cooperation:

• On startup, a firewall script inside the sandbox sets the default policy to drop all outbound traffic, then allows exactly one destination: the proxy's IP and port. IPv6 egress is dropped entirely. The script self-verifies the rules before user code runs.
• On Kubernetes, a NetworkPolicy backstop enforces the same restriction at the cluster level, so even a root escalation inside the sandbox cannot open a direct path to the internet or the internal network.
• The proxy identifies each sandbox by its source IP against a live registry of known sandboxes. An unknown source fails closed: no identity, no service.

The result is that "bypass the proxy" is not an instruction an agent can follow, no matter what a prompt injection tells it.

Layer 2: The proxy blocks internal targets and inspects requests

Because the sandbox can only talk to the proxy, the proxy must enforce where traffic actually goes. It blocks requests to private IP ranges, cloud metadata endpoints, loopback addresses, and anything that does not resolve to a globally routable destination. This closes the classic server-side request forgery path where a compromised workload pivots into the internal network.

For HTTPS, the proxy terminates TLS with a certificate authority the sandbox trusts (a standard enterprise inspection pattern), so it can classify the request: which app is being called, and which specific action, like "Gmail: send email" versus "Gmail: read messages." REST calls are matched by method and path; GraphQL calls are matched by parsing the operation in the body, since every GraphQL request looks like the same URL from the outside.

Layer 3: Per-action policy, with humans in the loop

Admins set one of three policies for each action an app supports:

When an ASK action fires, the request is parked at the proxy, before any credential is attached, and the user sees an approval card in the chat with a decoded, human-readable payload: for an email, the actual recipients, subject, and body the agent composed. The user can approve once, approve for the rest of the session, or reject. Unanswered requests expire and fail closed. Approvals are recorded durably in the database, with who decided and how, which gives security teams an audit trail for gated actions.

A request that matches a known app but no recognized action does not slip through: it is treated as an ASK for the whole domain. And DENY wins over every grant, so an admin block cannot be talked around.

Layer 4: Credentials exist only outside the sandbox

The proxy resolves real credentials at request time from encrypted storage: the user's OAuth token for the app being called, the organization's LLM provider key, or the sandbox's Onyx API token. OAuth tokens are refreshed lazily by the proxy itself, so even short-lived tokens never transit the sandbox. If a credential cannot be safely resolved, the request is blocked rather than forwarded with a placeholder.

One design detail matters for trust: each user authorizes each app individually through a normal OAuth consent flow, and the proxy verifies that a gated request comes from a session belonging to the same user the sandbox is registered to. Agents act with per-user, per-app grants, not a shared god-token.

The two models side by side

What This Makes Possible: Real Use Cases

The point of this architecture is not to slow agents down. It is to make workflows delegable that a sensible organization would otherwise never delegate. Most of these are non-technical.

The executive assistant that drafts but cannot fire off

An operations lead has an agent triage the inbox each morning: summarize what matters, draft replies, schedule follow-ups. With raw credentials, this is the exact setup that produced the deleted-inbox incident, and a single malicious email could instruct the agent to forward sensitive threads externally.

With credential injection, reading and summarizing runs under ALWAYS. Every send is an ASK: the user sees each drafted email, with real recipients and body text, and approves in one click or rejects. Deleting mail can be DENY outright. The agent does 95% of the work; the human keeps the 5% that is irreversible.

Support triage that answers from knowledge but escalates writes

A support team lets an agent read incoming tickets, pull answers from the internal knowledge base, and prepare responses. Reads from the ticketing system are automatic. Posting a public reply or closing a ticket asks first. If the team gains confidence in a category of response, the admin flips that one action to ALWAYS while leaving refunds and account changes gated. Access control becomes a dial, not a switch.

Finance operations without handing out banking-grade tokens

An analyst asks an agent to reconcile invoices: pull records from the ERP, cross-check against a spreadsheet, flag mismatches, and prepare correction entries. Finance credentials are among the most damaging to leak, and a conventional agent setup would park them in a sandbox that also runs downloaded code. Here the sandbox holds nothing. Reads flow; every write to a financial system surfaces as an approval with the exact payload; payment endpoints are DENY for everyone. Even a fully compromised sandbox cannot move money or exfiltrate the token that could.

Scheduled reports that run at 6 a.m. without a human awake

Recurring agent tasks, like a Monday-morning pipeline report pulled from the CRM and posted to Slack, create a dilemma: nobody is online to click "approve." The common workaround is to grant standing broad access, which quietly recreates the original problem.

Craft's answer is scoped pre-approval: a scheduled task can carry pre-approved grants for specific apps, and those grants apply only while that scheduled run is executing. The moment the run finishes, the grants stop applying. Admin DENY policies still override them. The 6 a.m. report posts on time; the same agent asked to do something else that afternoon parks for normal approval.

Sales research across the tools your team actually uses

A rep asks an agent to build an account brief: recent conversations from the CRM, open tickets, contract status, and public news. The agent touches four systems with four different credentials. In the injection model the rep authorized each app once via OAuth, reads run automatically under their own permissions (an agent working for a rep sees only what that rep can see), and any update back to the CRM is reviewed. No credential ever consolidates in one stealable place.

What to Look For in a Secure Agent Platform

Whether or not you evaluate Onyx, these are the questions that separate genuine access control from a settings page:

Two honest caveats apply to Onyx Craft as well. First, this architecture gates HTTP and HTTPS traffic, which covers modern SaaS APIs; it is not a filter for arbitrary raw network protocols, which is why the firewall denies everything except the proxy in the first place. Second, approval fatigue is real: if every trivial action asks, users start rubber-stamping. Good policy design (automatic reads, gated writes, denied destructive actions) matters as much as the enforcement machinery.

How to Adopt This Without Boiling the Ocean

1. Inventory what your agents can already touch. Most organizations discover standing OAuth grants and API keys issued to tools nobody reviews. Our CISO governance playbook covers this discovery phase in detail.
2. Stop issuing raw credentials to new agent deployments. Make "the agent never holds the secret" a procurement and architecture requirement, the same way "passwords are hashed" is.
3. Start with reads automatic, writes gated, destructive actions denied. This default is safe, immediately useful, and easy to explain to non-technical stakeholders.
4. Loosen policy with evidence, not optimism. Promote a specific action to automatic only after the approval history shows it is consistently approved and low-risk.
5. Prefer platforms you can audit. For self-hosted and regulated environments especially, enforcement code you can read beats attestations. Onyx supports cloud, self-hosted, and air-gapped deployment, so the proxy runs inside your boundary if it needs to.

The organizations getting value from agents in 2026 are not the ones that trust agents the most. They are the ones that built architectures where trust is mostly unnecessary: sealed sandboxes, placeholder secrets, policy at the network layer, and a human click in front of anything irreversible. Cisco found that 83% of organizations plan to deploy agentic AI while only 29% feel ready to do so securely. Credential injection is a large part of closing that gap, and it exists today.

---

Frequently Asked Questions

What is credential injection for AI agents?

Credential injection is an architecture where an AI agent runs without any real credentials. Its outbound requests pass through a proxy that identifies the agent, checks policy, and attaches the real API token or OAuth credential only as the request leaves for an approved destination. The agent can use services on your behalf without ever seeing or storing the secrets.

Why shouldn't I just give my AI agent an API key?

An agent's environment runs generated code, installs packages, and processes untrusted content like emails and web pages. Any secret inside that environment can be leaked through logs or dependencies, or misused if the agent is manipulated by prompt injection. A key the agent never holds cannot be stolen from it.

Does credential injection stop prompt injection attacks?

It does not stop an agent from being deceived, but it caps what deception can achieve. A manipulated agent still cannot reach unapproved destinations, cannot exceed per-action policy, and cannot complete a gated write without a human seeing the exact payload and approving it. Enforcement happens in network infrastructure, below the layer that language can manipulate.

What is the difference between a sandbox and a credential injection proxy?

A sandbox isolates where the agent executes; the proxy controls what the agent can reach and as whom. A sandbox alone still leaks authority if credentials are stored inside it. Combining a firewall-sealed sandbox with an injecting proxy means a full sandbox compromise yields placeholder strings and a locked network.

How do approvals work without slowing everything down?

Policy is per action. Low-risk reads run automatically, writes pause for a one-click approval showing exactly what will happen, and destructive actions can be blocked entirely. Users can approve a recurring action for the rest of a session, and scheduled tasks can carry pre-approved grants scoped to a single run.

Can non-technical teams use agents secured this way?

Yes, and they are arguably the main beneficiaries. The security machinery is invisible during normal work: a user connects apps with a standard "Sign in with..." flow, the agent works, and consequential actions appear as plain-language approval cards. No one manages tokens or firewall rules.

Does Onyx Craft's proxy work in self-hosted environments?

Yes. Onyx runs in cloud, self-hosted, and air-gapped deployments, and the egress proxy architecture is part of the open-source platform, deployable on Kubernetes or Docker. Self-hosted organizations supply their own app credentials, which stay inside their boundary.

---

This article builds on our series on enterprise AI agent security, including the ambient authority problem and the CISO's 90-day playbook for AI agent governance.