Security teams should treat borrowed trust as a control boundary, not a convenience. That means limiting what packages, assistants, tokens, and runners can do, then binding each action to a specific identity and expiry window. The goal is to reduce the amount of implicit trust that enters the workflow before code is approved or released.
What borrowed trust means in an AI-assisted workflow
Borrowed trust appears when a tool, model, package, or automation step inherits permission it did not independently earn. In AI-assisted development, that often shows up as an assistant acting through a developer’s session, a CI runner using broad repository tokens, or a package installation step reaching farther than the code itself should.
The practical problem is not that these components are useful, it is that they can silently carry authority across trust boundaries. Once that happens, a prompt, plugin, dependency, or runner can influence code, secrets, or release steps without the kind of explicit approval a security team would expect from a human-reviewed change.
That is why the right unit of control is the action, not the tool label. A code assistant may be acceptable for drafting, but not for creating releases, rotating secrets, or modifying production policy unless those actions are separately bounded and attributable.
How to constrain borrowed trust without breaking developer velocity
Security teams should break the workflow into small authority slices: local editing, dependency retrieval, test execution, build, signing, deployment, and post-merge automation. Each slice should have its own identity, scoped token, and expiry window so that a compromise or mistake in one step does not automatically extend to the next.
Where possible, use short-lived credentials, explicit approval points, and separate execution paths for human and automated actions. The goal is to avoid a world where one login, one token, or one runner can move from suggestion to release with no additional check.
For AI assistants and coding tools, the safest posture is to treat their outputs as untrusted until they are reviewed and committed under a different authority boundary. That means keeping the assistant away from high-value secrets, constraining file and network reach, and making sure tool calls cannot exceed the permissions needed for the immediate task.
This is also where identity-aware platform design matters. The AI Infrastructure Workload Identity Guide is useful because borrowed trust is often created by shared pipeline credentials, broad build identities, and overly capable service accounts rather than by the model itself. In parallel, the Agentic AI Security Policy Template helps teams formalise registration, ownership, oversight, and retirement for systems that act with delegated authority.
What good control boundaries look like in practice
Good control boundaries are observable. A security team should be able to answer which identity performed each action, what it was allowed to do, how long that permission lasted, and whether the action was reversible. If those questions cannot be answered from logs and policy, then the workflow still relies on borrowed trust rather than controlled delegation.
In mature setups, build and release systems do not reuse the same credentials that developers use for day-to-day work. Assistants can draft code or suggest changes, but they do not inherit broad repository, cloud, or secret-management rights by default. Runners and bots should authenticate as distinct principals with narrow scopes and enforced expiry, not as hidden extensions of a person’s login.
The other strong signal is that exceptions are rare and deliberate. If a tool needs elevated access for a special task, that access should be time-bound, recorded, and easy to revoke. If teams cannot revoke or rotate that authority quickly, then the workflow is still depending on standing trust.
The Zero Trust for AI Agents is a good fit here because it frames each action as something to verify and authorise, rather than something to permit once and assume safe thereafter. For the wider supply chain angle, AI Supply Chain Security and AI-BOM Guide is relevant when borrowed trust comes from packages, tools, or MCP servers that the workflow consumes.
Risk and Threat Considerations
Borrowed trust increases blast radius when an AI-assisted workflow can reach secrets, repositories, or deployment paths that were never intended for the assistant, runner, or package itself. The main security failure is privilege reuse, where a low-friction convenience layer inherits enough authority to alter code, exfiltrate data, or trigger deployment activity.
Failure mechanism: A trusted human or build identity is extended into an AI-driven step, then that step is exploited through prompt injection, dependency compromise, token theft, or overly broad automation scope.
Impact: Attackers can move from code suggestion to code execution, secret exposure, unauthorized release, or persistent access through the same borrowed authority that was meant to speed delivery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | AI tools and runners often authenticate as non-human principals. |
| IA-5 — Authenticator Management | Borrowed trust depends on short-lived tokens, rotation, and revocation. | |
| AC-6 — Least Privilege | The core issue is preventing assistants and runners from inheriting excess authority. | |
| Recommendation — Use IA-9 to authenticate non-human principals with scoped, accountable access. Manage token lifetimes tightly and rotate or revoke credentials quickly. Constrain each workflow principal to the minimum permissions needed for its task. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Assistants, runners, and service identities can become overprivileged quickly. |
| Recommendation — Audit and reduce excess permissions on non-human workflow identities. | ||
Practitioner Guidance
What to prioritise: Start with the identities and tokens that can reach code, secrets, and release systems, because those are the points where borrowed trust becomes a material security problem. Review whether assistants, runners, and packages are sharing human credentials or using distinct principals with their own expiry and scope.
What to verify: Confirm that every privileged action in the workflow is attributable to a specific identity and that the credential used for that action is short-lived, least-privilege, and revocable. If a step cannot be traced cleanly in logs, assume the boundary is too loose.
Practitioner takeaway: Treat AI assistance as delegated execution, not delegated trust. The safe pattern is narrow authority, short lifespan, and explicit accountability at each step, because convenience becomes risk the moment borrowed privilege can cross into approval, release, or secret access.
Related resources from NHI Mgmt Group
- How should security teams handle credentials in AI-assisted development workflows?
- How should security teams handle risks from AI browser extensions?
- How should security teams handle trust assumptions in LLM and AI agent workflows?
- How should security teams secure AI-assisted development without overwhelming AppSec workflows?