Who is accountable when an AI assistant exfiltrates a repository token from developer tooling?

Why This Matters for Security Teams

An AI assistant that can read developer prompts, inspect code, and reach external services is not a passive tool. Once it can handle repository tokens, the issue becomes accountability for a privileged workload that operates at machine speed and outside normal human intent. Traditional blame assignment misses the real failure mode: excessive token scope, weak workspace isolation, and insufficient approval gates.

This is why identity governance has to extend into developer tooling, CI/CD, and agentic workflows. The NIST Cybersecurity Framework 2.0 puts governance and access control at the centre of operational resilience, but the practical question is whether the organisation defined who may mint, store, and use a token in the first place. NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly secrets become distributed across tools and workflows once teams stop treating them as tightly governed assets.

In practice, many security teams encounter exfiltration only after an assistant has already copied a token into a prompt, log, or outbound request, rather than through intentional control design.

How It Works in Practice

Accountability usually sits with the organisation operating the environment, not the assistant itself. The assistant may be the immediate mechanism, but the control failure is almost always upstream: a token with unnecessary privileges, a development environment that can access secrets, and a policy that allows untrusted content to influence execution. Current guidance suggests treating assistant access as a workload identity problem, not a human login problem.

That means a few concrete controls matter more than blame narratives. First, issue short-lived credentials for narrow tasks rather than long-lived repository tokens. Second, bind access to workload identity and context, so a tool can prove what it is and what it is allowed to do at request time. Third, require real-time policy evaluation before any sensitive action, especially when the assistant can open network connections or call external APIs. Fourth, separate read access to source code from access to secrets, because many exfiltration events begin with simple context gathering and end with token reuse.

• Use just-in-time credential issuance for each task, with automatic revocation on completion.
• Keep secrets out of prompts, logs, and clipboard-adjacent workflows.
• Apply policy-as-code so access decisions are evaluated with runtime context, not static role assumptions.
• Limit assistants to the minimum execution surface needed for the job.

NHIMG’s coverage of the JetBrains GitHub plugin token exposure illustrates how developer tooling can become a secrets pathway when trust boundaries are too broad, while the Salesloft OAuth token breach shows the downstream impact when tokens are harvested and reused across connected systems. These controls tend to break down when assistants are embedded into high-trust developer workflows with persistent tokens and outbound network access, because the environment itself becomes the exfiltration channel.

Common Variations and Edge Cases

Tighter token controls often increase friction for developers, requiring organisations to balance speed against containment. That tradeoff is real, especially in fast-moving engineering teams where assistants are used for code review, dependency updates, or incident response.

There is no universal standard for this yet, but current guidance is converging on a few exceptions and edge cases. If an assistant is restricted to offline code analysis, accountability may focus more on repository hygiene and prompt filtering. If the assistant can execute commands, open tickets, or call SaaS APIs, the accountability scope expands to platform owners, application security, and identity governance teams. If secrets are stored in multiple places, such as local config, chat tools, and CI variables, the organisation may have created a shared failure condition rather than a single point of negligence.

NHIMG research in the State of Secrets in AppSec shows how fragmented secrets management and weak developer practice can turn a single exposed token into an ongoing exposure. The practical lesson is that accountability should map to the control owner who allowed persistent privilege, broad reach, and weak revocation, not merely to the person who noticed the leak. Where assistants are allowed to process untrusted content and invoke external endpoints, responsibility becomes shared across platform engineering, security, and the business owner of the workflow.

Related resources from NHI Mgmt Group

• Who is accountable when an AI assistant surfaces private code from a cached repository?
• Who is accountable when untrusted project configuration changes what an AI assistant sees?
• Who is accountable when AI tool use happens through unmanaged browser sessions?
• Who should be accountable when compromised npm packages spread through CI and developer systems?