Your agent has tools. Who holds the keys?

An AI agent that can read a GitHub issue, post to Slack, and triage email is useful. An AI agent that holds a long-lived API key with write access to every repository in your organization is a liability. The gap between those two sentences is the hardest unsolved trust problem in production agent deployment.

The credential sprawl is real#

The data is unambiguous. A 2026 survey of enterprise security teams found that 45.6% rely on shared API keys for agent-to-agent authentication, and 27.2% use custom, hardcoded authorization logic (Beam.ai, March 2026). The GitGuardian State of Secrets Sprawl 2026 report documented nearly 29 million new hardcoded secrets in public GitHub commits in 2025, with AI-assisted commits leaking at roughly double the base rate (Descope, May 2026).

This is not a minor hygiene problem. When an agent authenticates to a third-party API, it crosses a trust boundary. The agent may call that API at machine speed, without per-step human approval, using permissions that were scoped for a human who can exercise judgment. A single over-scoped token in an agent configuration does not risk one bad click — it can trigger hundreds of API calls before anyone notices (SSOJet, May 2026).

Security teams know this. 73% of CISOs are critically concerned about AI agent security risks, yet only 30% have mature safeguards in place (Aembit, July 2026). Forrester has predicted that an agentic AI deployment will cause a public breach leading to employee dismissals in 2026, with 97% of breached organizations found to lack proper AI access controls (SecureAuth, 2026).

Why traditional approaches break for agents#

The industry is converging on several observations about why existing credential patterns fail for AI agents.

Shared API keys are the default — and the most dangerous. A long-lived key stored in an environment variable or configuration file gives the agent unlimited access until someone remembers to rotate it. If the agent is compromised, the attacker inherits the full scope of that key.

Human credentials give agents dangerously broad permissions. When an agent uses a personal OAuth token, it typically gets the same access as the human who authorized it — but without the human's ability to exercise discretion. An agent that can read a calendar can probably also delete events.

Permissions accumulate without review because no one owns the agent's access lifecycle. An agent may start with read-only access to a repository, then receive additional scopes as the team adds features. The original narrow scope is never revoked, and the full access surface is never audited.

Agents cross trust boundaries. A single agent workflow might traverse cloud provider APIs, SaaS platforms, and third-party AI services, each with its own authentication model. No unified identity layer spans the full path (Aembit, July 2026).

What a secure agent credential model looks like#

The emerging consensus from the OAuth and identity communities is clear. Agent credentials should be:

• Scoped, not global. Each agent should receive only the permissions it needs for its declared task, not a blanket token that covers every possible action.
• Short-lived, not permanent. Tokens should expire in minutes, not months. The agent's runtime should handle renewal transparently.
• Identity-bound, not shared. Each agent should have its own credential, so that revoking one agent's access does not affect others, and audit trails remain unambiguous.
• Separated from the bundle. The agent's instructions and configuration should never contain credentials. Credentials should live in a separate, encrypted store and be injected at runtime.

How Aleph's architecture addresses the credential problem#

Aleph was designed around these principles from the start. Here is how the product's architecture maps to the security requirements the industry is now formalizing.

Connections declare what the agent needs — not how to get it#

An agent bundle includes an optional connections.toml that lists the third-party apps the agent requires:

[[connections]]
id = "github"
required = true

This declares a dependency. It does not contain a token, a client ID, or any credential. The bundle remains safe to inspect, share, and clone without exposing secrets.

Scoped OAuth handles authorization#

When you enable an agent in Aleph, you authorize each declared Connection through a standard OAuth flow. The credential is stored in the agent's dashboard scope — personal, organization, or team — and is never placed in the bundle.

Authorizing GitHub once in a scope lets every agent in that scope that declares GitHub use it. But each agent still only gets the tools its declared Connection requires. This is the identity-bound, scoped model the security community is asking for.

The Vault keeps secrets and variables outside the bundle#

Aleph's sandbox.toml declares configuration references without storing values:

[runtime.env]
GITHUB_TOKEN = "{{secrets.GITHUB_TOKEN}}"
REPOSITORY = "{{vars.REPOSITORY}}"

Secrets and variables are stored in the scoped Vault and resolved at runtime. The bundle never contains a real credential. After cloning, the references copy over but the values do not — the new owner must supply their own.

Exact-scope resolution prevents cross-boundary leakage#

Values are resolved from the agent's exact scope — personal, organization, or team — with no fallback. A value with the same name in your personal Vault cannot satisfy a team agent. This prevents the accidental permission escalation that occurs when a shared credential is used across trust boundaries.

Cloning never copies credentials#

When you clone a public agent, you get its bundle — instructions, schedules, skills — but never its Connections, secrets, or channel credentials. The clone starts with missingSecrets and missingVariables as a setup checklist. You must authorize each Connection in your own scope before enabling the agent. This is the least-privilege, identity-bound model by design.

The principle: credentials are not bundle content#

The hardest part of the agent credential problem is not technical. It is architectural. Most agent frameworks treat credentials as configuration — a file, an environment variable, a JSON blob. Once credentials are in the bundle, they travel with it: into version control, into clones, into logs.

Aleph's architecture makes a different choice. Credentials are not bundle content. They are runtime state, resolved from a scoped, encrypted store, and never mixed with the agent's instructions. The bundle is inspectable, shareable, and cloneable because it contains zero credentials. The runtime is secure because credentials are injected only for the turn that needs them, in the scope where they belong.

If your agent framework cannot answer the question "where are the credentials?" with a single, auditable answer, the credentials are probably in the wrong place.

What to check#

If you are evaluating an agent platform for production use, ask these questions:

1. Can you inspect the bundle without seeing credentials? If the answer is no, the bundle is not safe to share or clone.
2. Are credentials scoped to the agent's identity, or shared across all agents? Shared credentials create blast radius.
3. Is there a separate, encrypted store for secrets? If secrets are in environment variables or configuration files, they are in the wrong place.
4. Does cloning copy credentials? If yes, the clone inherits the original's access surface — and the original cannot revoke it.
5. Are credentials resolved from the agent's exact scope? Cross-scope fallback creates the permission escalation paths that the identity community is warning about.

The credential problem is not theoretical. It is the first production gate that most agent deployments hit. The architecture that solves it before you deploy is the one that saves you from the breach that forces you to redesign.