TL;DR: AP-004 Credential Harvesting is a coding-agent security pattern where an AI agent encounters credentials while pursuing a legitimate engineering task. A request such as "debug this failed deployment" can lead the agent through CI workflows, logs, deployment scripts, environment variables, kubeconfigs, cloud CLI sessions, registry tokens, or GitHub Actions secrets. Traditional malware searches for credentials because credentials are the objective. A coding agent may discover credentials because credentials are in the path of the objective. Defending AP-004 requires runtime security that treats credentials as delegated capability, tracks how authority enters the agent workflow, and enforces credential boundaries before useful debugging becomes unbounded authority.
A developer asks an AI coding agent to debug a failed deployment. The agent starts where any engineer would start: it opens the deployment workflow, checks environment configuration, inspects the last failed run, and follows the error. The logs mention a missing token. The workflow references a GitHub secret. A helper script expects a kubeconfig. Nothing about that path has to look like credential theft.
The agent is trying to complete the task. It is following the shape of the system. It is reading the same files a human engineer would read. By the time it finds a token reference or a local credential file, the discovery may feel like progress. That is the uncomfortable part of Credential Harvesting in AI coding agents: the security risk is not always defined by malicious intent. It is defined by the capability the credential creates once it enters the agent's working context.
In one sentence: Credential Harvesting in AI coding agents is the workflow-level pattern where legitimate task progress leads to credential discovery, credential use, or authority expansion.
The most dangerous credential is often the one an agent was allowed to find. The question is not only whether a secret exists. It is how the agent came to possess or invoke the authority behind it.
Attack card
| Attack ID | AP-004 |
| Name | Credential Harvesting |
| Pattern | A coding agent discovers, reads, infers, invokes, or exposes credentials while pursuing a legitimate task, causing authority to enter the agent workflow. |
| Primary condition | Agents with access to deployment workflows, CI logs, environment variables, local configuration, cloud CLI state, kubeconfigs, SSH keys, registry tokens, package managers, or authenticated tools. |
| Common triggers | Failed deployments, CI authentication errors, integration-test failures, private package issues, cloud role assumption errors, Kubernetes debugging, release automation, and verbose tool output. |
| Security impact | Repository modification, package publishing, infrastructure mutation, cluster access, host access, cloud enumeration, release automation, or lateral movement through credentials that were discovered during normal work. |
| Key distinction | Traditional credential theft begins with credentials as the objective. Agent Credential Harvesting can begin with a valid engineering task and drift into credential authority. |
| Detection challenge | Secret scanners may see no new secret committed. IAM may see an authorized identity. EDR may see normal developer commands. The runtime must explain how credential authority entered the agent's context. |
Why agents need credentials
Software engineering work is full of authenticated systems. Deployments need cloud access. Tests may need database credentials. CI workflows need tokens to publish artifacts, comment on pull requests, pull private packages, or assume cloud roles. Local development often relies on .env files, kubeconfigs, SSH keys, registry tokens, and provider-specific CLI state. Even when secret values are stored correctly, references to those secrets are scattered through workflows, scripts, manifests, docs, and config files.
A useful coding agent eventually runs into this terrain. If the task is "fix the deployment," the agent needs to understand how deployment authenticates. If the task is "debug the integration test," it may need to learn which database or API token the test expects. If the task is "update the GitHub Action," it may need to understand how workflow authentication works. GitHub Actions, for example, creates a GITHUB_TOKEN for workflow jobs so automation can authenticate in the job context, and GitHub documents that the token is also available through the github.token context.
Agents do not have to be malicious to encounter secrets. They only have to be useful.
Traditional credential theft vs agent credential harvesting
Traditional credential theft has a familiar shape. Malware searches common paths, dumps environment variables, scrapes browser stores, reads SSH keys, exfiltrates tokens, and uses them elsewhere. The intent is clear: find credentials, steal credentials, use credentials.
Agent Credential Harvesting looks different. The session often begins with a legitimate request. The agent is trying to deploy a service, fix a failing test, configure a tool, or repair infrastructure code. It follows references from files to scripts to workflows to environment variables. It discovers a credential because the system points toward one.
The resulting security risk is not defined by the agent's stated intent. It is defined by the capability the credential creates. A GitHub token can change repository state. A cloud access key can inspect or mutate infrastructure. A kubeconfig can reveal cluster access. An SSH key can cross host boundaries. A registry token can pull or publish packages. A CI secret can convert a local coding task into an automated release action.
This is Authority Accumulation. The agent begins with a task. Each discovered credential expands what the agent can now affect. The distinction matters because many controls are built to detect malicious credential seeking. They look for exfiltration, known secret patterns, suspicious file paths, or unusual process behavior. An agent following a deployment script may not look like malware. It may look like an engineer debugging a deployment.
Workflow examples
Consider a staging deployment failure. The agent reads .github/workflows/deploy.yml, sees that the job assumes a cloud role, follows repository docs to a setup script, and discovers that local reproduction expects an environment variable such as AWS_ACCESS_KEY_ID. The agent asks to inspect the local shell environment because the deployment error says authentication failed. The immediate request sounds reasonable. The task is about deployment. The error is about authentication. But a boundary has been crossed: the agent has moved from understanding the deployment to discovering authority that can act on infrastructure.
The same pattern appears in Kubernetes debugging. A developer asks why a service is failing in staging. The agent reads Helm values, checks a kubeconfig path in the docs, and suggests running kubectl with the current context. A kubeconfig is not just a config file. It can encode cluster endpoints, users, client certificates, tokens, and contexts that select where commands execute.
CI systems create another version. A workflow fails when publishing an artifact. The agent reads the action, sees a secret reference, and checks whether the token is passed correctly. GitHub's documentation for GITHUB_TOKEN explains how workflows can make authenticated API requests and adjust token permissions. A helpful agent may learn that the workflow already has repository-scoped authority before it proposes the next change.
Local development has its own paths. A .env file may contain test credentials. A cloud CLI cache may contain active sessions. An SSH agent may hold keys. A package manager may have registry credentials. Claude Code Action's security documentation warns that full tool output can include environment variables, file contents, API responses, command outputs, tokens, credentials, and other sensitive system information. In each case, the agent is not performing a classic credential dump. It is following the work.
Why existing controls miss the pattern
Secret scanners, push protection, secrets managers, and least privilege all remain necessary. They look at a different part of the workflow. GitHub push protection is designed to keep hardcoded credentials from reaching repositories by blocking pushes that contain detected secrets. That is a valuable boundary. It does not address an agent reading a local .env file during debugging or discovering that a workflow token can publish an artifact.
OWASP's Secrets Management Cheat Sheet describes the importance of auditing who requested a secret, whether requests were approved or rejected, when secrets were used, when they expire, and whether expired secrets are reused. Those practices reduce exposure and improve accountability. They do not remove credentials from engineering workflows. CI/CD, deployment, and debugging still need controlled access to authority.
The agent discovers credentials while executing a task. The discovery happens through reads, command outputs, workflow references, environment inspection, local tool state, and error-driven debugging. A scanner may see no new secret committed. IAM may see an authorized user context. EDR may see normal developer commands. The runtime sees something those layers often miss: how authority entered the workflow.
Short answer for security teams: AP-004 is not only a secret-detection problem. It is a runtime authority problem. The key question is whether the credential discovery or credential use is justified by the user's authorized task.
Credential Boundaries
Credential Boundaries deserve to become their own runtime security boundary. A credential is not only sensitive data. It is delegated capability. Once an agent can read, infer, or invoke it, the agent may be able to change what systems it can affect.
That boundary is crossed in several ways. The agent may read a secret value directly from a file or environment variable. It may learn a secret reference in a workflow. It may call a CLI that already has an authenticated session. It may trigger a CI job whose token is injected automatically. It may read logs that contain redacted or partially exposed values. It may request approval to run a command whose output includes credential material.
Not all of these should be treated the same. Seeing that DEPLOY_TOKEN exists is not the same as reading its value. Running a command with a credential is not the same as printing it. Using a repository-scoped token in CI is not the same as accessing a cloud admin key on a developer machine. The runtime posture should change as the agent approaches capability.
Before credential discovery, the agent may be doing code comprehension. After credential discovery, it may be operating with new authority. The same command can mean different things depending on whether the agent already knows where credentials live or has access to a session that can use them. "Allow file read" does not capture "this file contains deploy authority." "Allow command" does not capture "this command will run with an authenticated cloud context." "Allow log output" does not capture "this output may place a token into the agent's context window."
Detection and mitigation
Defending against Credential Harvesting should not make agents blind. A coding agent that cannot inspect workflows, deployment configs, or test environments will be much less useful. The runtime has to preserve workflow awareness around credential discovery.
When an agent moves from repository comprehension into credential-adjacent territory, the next decision should change. Reading .env files, inspecting cloud CLI state, touching kubeconfigs, querying environment variables, reading CI secret references, or running commands likely to print token-bearing output are not equivalent to ordinary code navigation. A task-scoped deployment investigation may justify seeing which secret is referenced, but not printing the secret value. A test debug session may justify using a low-privilege test credential, but not reading a production token. A CI repair task may justify editing how a secret is passed, but not expanding token permissions.
Approval should carry the credential boundary into the prompt. "Run env" is not enough. The reviewer should know when a command may expose environment variables to the agent context. "Read kubeconfig" is not enough. The reviewer should know whether the file grants access to a production cluster.
Containment matters as well. Credentials should be scoped, short-lived, task-bound, and unavailable by default to agents that do not need them. Commands that can print credential material should be wrapped or redacted. Package installs, cloud CLIs, kubectl, SSH, and CI tools should be treated as credential-using interfaces, not ordinary commands. The runtime should also remember what has been discovered: if an agent has already learned that a deployment token exists, later actions involving deployment scripts, release workflows, or network access should be evaluated with that knowledge in mind.
Where Gensee Crate fits
Gensee Crate is built for long-horizon runtime visibility and enforcement around AI coding agents. For AP-004, the important distinction is that Crate can observe how credential-adjacent context enters a workflow: user request, agent tool call, file read, shell command, environment inspection, command output, approval, and later operation. That deeper and longer view matters because credential risk rarely appears as one isolated event.
Crate's role is not to replace secret managers or push protection. Those systems remain essential. Crate adds runtime evidence around the agent's path to authority. It can distinguish ordinary repository comprehension from credential-adjacent discovery, preserve provenance when credentials or secret references enter the agent context, and enforce higher-friction decisions before the agent moves from debugging into credential use.
In practice, that means an agent can still inspect deployment logic, CI configuration, and test setup. But when the workflow approaches .env files, kubeconfigs, cloud CLI state, GitHub tokens, registry credentials, or commands likely to print sensitive output, the runtime can redact, block, scope, or require approval with the right context attached.
Questions for engineering and security teams
Can your agent read local .env files, kubeconfigs, SSH keys, package-manager credentials, cloud CLI state, or CI logs? Can it run commands that print environment variables or authenticated tool output? Can it trigger workflows where secrets are automatically injected? Can your approval prompts explain that a command may expose credential material, or do they only show the command text?
Can your logs reconstruct how a credential entered the agent's context? Can they show whether credential discovery was justified by the task? Can they distinguish reading a secret reference from reading a secret value, and reading a value from acting with it? If not, the organization may have secret management, but not agent-runtime credential security.
Frequently asked questions
What is AP-004 Credential Harvesting?
AP-004 Credential Harvesting is a coding-agent security pattern where an AI agent discovers or uses credentials while pursuing a legitimate task such as debugging a deployment, fixing CI, repairing infrastructure code, or reproducing an integration-test failure.
How is agent credential harvesting different from traditional credential theft?
Traditional credential theft usually starts with credentials as the objective. Agent Credential Harvesting can start with a legitimate engineering task, then move toward credentials because workflows, logs, scripts, environment variables, or authenticated tools point the agent there.
What is Authority Accumulation?
Authority Accumulation is the expansion of what an agent can affect as it discovers, reads, invokes, or routes through credentials such as tokens, kubeconfigs, SSH keys, registry credentials, cloud CLI sessions, or CI secrets.
Why do secret scanners not fully solve AP-004?
Secret scanners and push protection reduce leaked hardcoded credentials, but AP-004 can happen without committing a secret. The issue is how credential authority enters the agent's working context during runtime.
How does Gensee Crate help with Credential Harvesting?
Gensee Crate connects user requests, agent tool calls, file reads, shell commands, credential-adjacent events, approvals, and later operations across a runtime trajectory, allowing credential boundaries to be enforced before legitimate debugging becomes unbounded authority.
Sources
This post references GitHub's documentation for GITHUB_TOKEN, GitHub's guide to using GITHUB_TOKEN in workflows, GitHub's push protection documentation, the OWASP Secrets Management Cheat Sheet, Anthropic's Claude Code Action security documentation, and the open-source Gensee Crate repository.