Contact Open demo
Solutions / By agent

Coding agents hold real credentials

Cursor, Claude Code and Codex in CI act with the keys and roles of the developer or the pipeline. nerl0 shows what each one can reach.

An agent reaches what its credentials reach

A coding agent has no access of its own. It borrows the session of the developer or the role of the pipeline, and with it every door those credentials open.

See the Security Graph
WHERE THE AGENT RUNSCREDENTIALS IT INHERITSWHAT THEY OPENCursorDeveloper machineClaude CodeDeveloper machine1CodexCI pipelineUses credentialUses credentialUses credentialRepository tokenPersonal access tokenCloud CLI sessionSigned-in profile3deploy-roleIAM roleCI secretPipeline secretCan readCan readCan accessCan readRepositoriesPrivate code and historyCloud accountBuckets, queues, secretsBreakpoint · Read6Production dataCustomer and payment data
Environment the agent can read ⌄
# developer machine
AWS_PROFILE=prod-admin
GITHUB_TOKEN=ghp_••••••••••••
# CI pipeline
DEPLOY_ROLE_ARN=arn:aws:iam::•••:role/deploy
STRIPE_SECRET=sk_live_••••••••
# nerl0 reads the roles and grants, never these values

Three places the credentials come from

Where an agent runs decides which keys it can see. nerl0 reads the roles and grants behind them, through read-only connectors.

  • Developer machineCloud CLI sessions and tokens already signed in on the laptop.
  • CI pipelineSecrets and deploy roles that the pipeline passes to every job.
  • RepositoriesTokens that let an agent read history, open pull requests or push.

Know which identity each agent runs as

A list of agents is not enough. The useful column is the identity behind each one, and what that identity can reach.

  • Same agent, different reachClaude Code on a laptop and Claude Code in CI run as different identities.
  • Shared identities stand outOne deploy role behind several agents is one decision, not several.

Coding agents

Every agent, the identity it runs as and what that identity reaches.
AgentRuns onRuns asPlatformReaches
Claude CodeDeveloper laptopmaya.chen via SSOProduction data
CursorDeveloper laptopgithub-user tokenAll repositories
CodexCI pipelinedeploy roleProduction data
Claude CodeCI pipelineci-runner service accountPrivate repositories
Can assumeBreakpoint · Read2codex-ciCoding agent3deploy-roleIAM role6prod/payments/stripe-keySecrets Manager secret

Follow the path to production data

nerl0 traces from the agent through the role it can assume to the secret or store it can read, and marks the one grant worth cutting.

  • Authority, not alertsEvery step is a granted relationship you can check.
  • One breakpointCut a single grant and the path is gone.

Give each agent its own, narrow identity

The fix is rarely to remove the agent. It is to stop sharing one broad identity between all of them.

BEFORE · ONE SHARED IDENTITYCursorDeveloper machineClaude CodeDeveloper machine1CodexCI pipelineUses credential3deploy-adminShared by all three agentsCan readCan accessBreakpoint · ReadAll repositoriesPrivate code and historyCloud accountBuckets, queues, secrets6Production dataCustomer and payment dataAFTER · ONE IDENTITY PER AGENTCursorDeveloper machineClaude CodeDeveloper machine1CodexCI pipelinecursor-devNarrow identityUses credentialclaude-devNarrow identityci-deployNarrow identityCan readRepositoriesRead onlyCan readStaging accountNo production accessCan deployOne serviceOnly what it deploysNo agent holds a path to production data.

Questions to ask first

Four questions from the library that tell you where coding agents stand today.

Browse the Question Library
Incident TrackerA build-tool attack that used AI command-line tools

A compromised package ran locally installed AI command-line tools to search developer machines for secrets. What the tools could reach was decided by the credentials already on the machine.

Read it in the tracker →

More solutions

Other ways into the same map of authority.

Browse the Academy

The terms behind this page

Short definitions, in plain words.

All terms

See what your coding agents can reach.