What breaks when an agent process stores model and GitHub tokens in its environment?

Why This Matters for Security Teams

When an agent process holds model and GitHub tokens in its environment, the runtime stops being a bounded execution context and becomes a reusable credential cache. That changes the threat model immediately: prompt injection, malicious issues, poisoned webpages, or compromised tools can aim at the agent’s own environment and retrieve secrets that were never meant to leave the task boundary. The risk is not just theft during execution. It is persistence, because the same token can often be reused later, outside the original session.

This pattern is directly reflected in recent NHIMG research. In CrewAI GitHub Token Leak, token exposure showed how quickly an agent credential can turn into source-code access. NHIMG’s OWASP NHI Top 10 also frames secret handling as an identity control issue, not just a deployment detail. That aligns with the OWASP Agentic AI Top 10, which treats credential exposure as a core agentic failure mode. In practice, many security teams encounter this only after an agent has already chained a tool call into an external leak, rather than through intentional secret lifecycle design.

How It Works in Practice

The safer model is to treat the agent as an ephemeral workload, not a human-like account with permanent credentials. Instead of placing model keys or GitHub tokens in environment variables, use workload identity and per-task authorization so the process proves what it is, then receives only the access needed for that one action. Current guidance suggests short-lived tokens, runtime minting, and immediate revocation on task completion, especially where the agent can browse, read issues, open pull requests, or call external APIs.

That means separating identity from secret storage. A workload identity, such as SPIFFE/SPIRE or OIDC-backed service identity, establishes cryptographic proof of the workload itself, while a policy engine decides whether a given request is allowed at that moment. In agentic environments, runtime policy evaluation matters more than static RBAC because the agent’s next step is not fully predictable in advance. NIST’s AI Risk Management Framework and CSA’s MAESTRO agentic AI threat modeling framework both support this kind of contextual control.

• Issue secrets per task, not per process lifetime.
• Bind access to the agent’s workload identity and current context.
• Keep tokens short-lived and revoke them as soon as the action ends.
• Never let the agent read reusable secrets unless there is no alternative.
• Log secret issuance and secret use separately for forensic review.

NHIMG’s CoPhish OAuth Token Theft via Copilot Studio shows why this matters: if the agent can be induced to expose or replay a token, the attacker inherits the credential, not just the session. These controls tend to break down in long-running CI runners, shared developer boxes, and containerized agents that inherit environment variables from parent processes because those environments make token discovery and reuse far too easy.

Common Variations and Edge Cases

Tighter secret handling often increases operational overhead, requiring organisations to balance developer convenience against compromise containment. That tradeoff is real, especially when teams want agents to work across GitHub, internal APIs, and model endpoints without repeated logins. Current guidance suggests avoiding one global token per agent and instead partitioning access by tool, repo, and task class, but there is no universal standard for this yet.

The main edge case is local development and early prototyping. Teams often place model keys in environment variables because it is simple, but that convenience becomes risky once the same pattern reaches shared runners, agent orchestration platforms, or incident-response automation. Another common exception is when a vendor SDK expects environment-based configuration; in that case, the better pattern is to inject a short-lived secret at process start, then remove it from memory and logs as quickly as the stack allows. The State of Secrets Sprawl 2025 is a reminder that GitHub-related leakage is not theoretical, and Ultimate Guide to NHIs places this inside the broader non-human identity lifecycle problem.

For high-autonomy agents, best practice is evolving toward eliminating standing secrets entirely and relying on brokered access, just-in-time issuance, and request-time authorization. That model is harder to deploy, but it is the only one that scales when the agent can chain tools, follow links, or act on untrusted content without a human in the loop.

Related resources from NHI Mgmt Group

• What breaks when an agent can read its own environment variables and tokens?
• What breaks when teams review only the agent object and not the blueprint?
• What breaks when Entra Agent ID accountability roles are missing?
• What breaks when ownership for an agent is tied to the person who built it?