04 / 25
Identity, Secrets & Trust Boundaries
Core Questions
- Who is an agent, cryptographically?
- What credentials can it hold?
- How long do identities live?
An agent with your AWS keys is just a very expensive way to delete your infrastructure. Identity and secrets management for agents isn't about convenience. It's about limiting blast radius. When (not if) something goes wrong, how much damage can happen?
The rule: agents should not impersonate developers
The agent writes code. Humans review and approve it. That separation only works if the agent has its own identity and its own scoped credentials.
- Accountability: logs must say "the agent did this," not "the developer did this."
- Least privilege: the agent gets the minimum it needs for a task, not a human’s full access.
- Revocation: you should be able to disable the agent without locking out developers.
- Separation of duties: humans approve; agents execute.
This is an area where tooling is still catching up. Don’t wait for perfect tools before enforcing the principle.
Who is an agent, cryptographically?
Agents need identity for two reasons: accountability (who did this?) and authorization (what are they allowed to do?). Both require the agent to prove who it is.
Agent Identity Approaches
Dedicated machine identity
A dedicated identity in each system the agent touches (GitHub, your secret manager, your cloud IAM, your VPN). Simple but coarse: one identity for many actions unless you add more structure.
Per-task identity
Each task gets a unique, short-lived identity. More complex to set up but better for audit trails and least privilege. When a task ends, its identity is revoked.
Workload identity (cloud-native)
Cloud providers offer workload identity — GCP Workload Identity, AWS IAM Roles for Service Accounts, Azure Managed Identity. The environment proves identity to cloud services without long-lived keys.
SPIFFE/SPIRE
Cryptographic identity framework for workloads. Agents get X.509 certificates that prove their identity. Enterprise-grade but complex.
For most teams: start with a dedicated machine identity (often a GitHub App + a cloud identity). As you scale, move toward per-task identity for stronger audit trails and tighter scoping.
The important part is that the agent identity exists everywhere the agent connects: GitHub, your secret manager, your VPN, internal APIs, artifact registries. Don’t “borrow” a human identity just because it’s easy.
GitHub: don’t hide agent actions behind a human
GitHub doesn’t give you a magic “bot account” button that solves this for you. In practice, you use a GitHub App (preferred) and/or a dedicated machine user account to represent the agent.
- Prefer agent-authored branches and PRs. Protect main so the agent can’t bypass review.
- Default workflow: agent pushes commits and opens a PR; a human approves and merges.
- Don’t rely on Co-authored-by as a substitute for identity. If the agent wrote the code, the agent should be the author in your systems of record.
- Make human review explicit: required approvals, CODEOWNERS, and merge permissions scoped to humans.
GitHub Apps are usually the cleanest path for scoped, revocable access. Machine users are still useful for git-native workflows (commit authorship, SSH keys), but treat them like a production identity: minimal permissions and clear audit trails.
What credentials can agents hold?
The principle is simple: least privilege, shortest lifetime. Agents should have exactly the credentials they need for the current task, and those credentials should expire as soon as the task ends.
Concretely: don’t forward a developer’s SSH agent into an agent runtime. Don’t inject a developer’s personal tokens. Don’t copy a human’s ~/.config into an agent environment. Those are all forms of impersonation.
Safe for agents
- ✓Read-only API tokens
- ✓Scoped GitHub tokens (repo only)
- ✓Dev/staging database credentials
- ✓Short-lived STS tokens
- ✓Artifact registry pull secrets
Never give agents
- ✗Production database credentials
- ✗Admin/root cloud credentials
- ✗Organization-wide API keys
- ✗Payment/billing system access
- ✗Long-lived personal access tokens
The credential scoping hierarchy
Secret injection patterns
Agents need secrets to do their work, but secrets shouldn't live in the agent's environment permanently. Inject them just-in-time, scoped to the task.
Secret Injection Methods
Secrets management platform. Inject secrets as environment variables at runtime. Secrets never touch disk. Audit logs for every access.
Enterprise secrets management. Dynamic secrets that are generated on demand and automatically revoked. Powerful but complex.
Cloud-native secrets
AWS Secrets Manager, GCP Secret Manager, Azure Key Vault. Integrated with cloud IAM. Secrets injected via SDK or environment.
GitHub Actions secrets
For CI-based agent workflows. Secrets injected as environment variables in the runner. Scoped to repo or org.
Just-in-time injection pattern
# Agent task script #!/bin/bash # 1. Authenticate with identity export DOPPLER_TOKEN=$(get-task-token) # 2. Run with injected secrets (never written to disk) doppler run --config agent-dev -- \ npm test # 3. Token expires automatically when task ends # No cleanup needed - task-scoped credential is gone
Provisioning: mint agent creds, don’t reuse human creds
The missing piece in many teams is provisioning: how the agent gets credentials at all. The safest pattern is that your orchestrator (or runtime platform) mints short-lived, scoped credentials for the agent when a task starts, and they die when the task ends.
- The runtime proves identity (workload identity / OIDC / attestation).
- The broker issues task-scoped tokens and records audit metadata (task ID, repo, actor).
- Secrets are injected just-in-time and never stored in the workspace.
- Expiry and revocation are enforced centrally; disabling the agent disables access everywhere.
If you skip this, you’ll end up “temporarily” using developer credentials forever.
Trust boundaries
A trust boundary is a line you draw: on one side, trusted; on the other, untrusted. Agents should operate in a zone with clear boundaries about what they can and cannot access.
Example: Agent trust zones
Zone 1: Full access
- • Dev environment databases
- • Feature branch repositories
- • Test infrastructure
- • Local services
Zone 2: Limited access
- • Staging databases (read-only)
- • Main branch (via PR only)
- • Shared dev services
- • External APIs (rate-limited)
Zone 3: No access
- • Production databases
- • Customer data
- • Billing/payment systems
- • Admin consoles
Enforce boundaries at the network level (see Guide 11: Policy & Guardrails). The agent's environment shouldn't have a network route to Zone 3 systems. No credential = no access, but no network route = definitely no access.
Credential lifetime
Shorter is better. A credential that lives for 15 minutes can do less damage than one that lives forever.
Credential Lifetime Guidelines
Per-task credentials
Lifetime: task duration + small buffer (max 1 hour). Automatically revoked when task completes.
CI workflow credentials
Lifetime: workflow duration. GitHub Actions OIDC tokens are already short-lived and scoped to the workflow run.
Service account tokens
If you must use long-lived tokens, rotate them frequently. Monthly at minimum, weekly is better.
Outbound network control
Credentials get you in the door. Network control determines which doors exist. Even if an agent somehow gets a production credential, it can't use it if there's no network path to production.
Network restrictions for agent environments
What goes wrong
Shared credentials
Agent uses a developer's personal access token. When something goes wrong, you can't tell if it was the human or the agent. No accountability.
Impersonation by convenience
The agent “just uses whatever credentials the developer has” (SSH forwarding, copied configs, cached auth). You get speed in the short term and an unbounded blast radius in the long term.
Over-provisioned access
Agent has admin credentials "just in case." Agent hallucinates a need to modify IAM policies. Now your cloud account is compromised.
Long-lived secrets
Credentials never expire. Agent environment is compromised six months later. Old credentials still work. Attacker has persistent access.
Secrets in logs
Agent logs its environment variables for debugging. Credentials appear in logs. Logs are stored in an insecure location. Credentials leaked.
Summary
- →Agents need their own identity — don't share human credentials.
- →Least privilege: only the credentials needed for this specific task.
- →Shortest lifetime: credentials should expire when the task ends.
- →Network boundaries enforce trust zones. No route = no access.
Related Guides
Stay updated
Get notified when we publish new guides or make major updates.
(We won't email you for little stuff like typos — only for new content or significant changes.)
Found this useful? Share it with your team.