TL;DR: AI-assisted development changes who creates and operates software, and the article argues that authorization must be designed into the architecture rather than bolted on later, according to 1Password’s discussion with Vercel’s Tom Occhino. The security question is no longer whether tools can be called, but how untrusted code, inherited permissions, and just-in-time access are prevented from turning into standing risk.
At a glance
What this is: This podcast discussion argues that AI agent access control is moving left into developer workflows because tool-using agents need architecture-level boundaries, not retrofitted permission checks.
Why it matters: IAM and security teams need to design for agent-driven access at build time, because inherited permissions, exposed secrets, and uncontrolled outbound actions can turn fast delivery into standing risk.
Context
AI-assisted development changes the access model as much as it changes the development model. When an agent can call tools, inherit credentials, and act inside a workflow, the security question is no longer whether the code works but whether the identity model around it is constrained.
The problem is not simply untrusted code. It is the combination of tool invocation, shared credentials, and weak scoping that lets a developer workflow become an access path. That is an NHI governance issue because the agent and the runtime both need explicit authorisation boundaries.
The article frames this as a design-time decision, which is the right place to start. Once an AI workflow has access to production secrets or broad tokens, later review does not recover the original control boundary.
Key questions
Q: What breaks when unvetted AI tools inherit developer credentials?
A: The security boundary breaks because the tool does not need to compromise authentication in the classic sense. It inherits whatever the developer already has, including cloud keys, database passwords, and API tokens. That makes local productivity tools a direct credential-exposure path and turns ordinary endpoint activity into production risk.
Q: Why do AI agent workflows need authorisation earlier in the development process?
A: Because the agent can choose actions while the work is being done, not after a human has finished planning it. If access is decided only after deployment, the workflow may already have used secrets, called tools, or reached external systems. Early authorisation makes the access model part of the architecture instead of a cleanup exercise.
Q: How do organisations know whether sandboxing is actually reducing AI agent risk?
A: They test for what happens after a breakout. If the workload can still read secrets, open new outbound connections, or reach internet-exposed systems, the sandbox is not reducing blast radius enough. The useful signal is not whether the sandbox exists, but whether escape leaves the workload with usable authority.
Q: Should organisations use just-in-time access for AI-enabled developer workflows?
A: Yes, when the workflow touches real systems or secrets. Just-in-time access reduces standing privilege and limits how long a credential remains useful, which matters when an AI assistant can move quickly inside a development session. The control is most effective when paired with environment checks and approval before execution proceeds.
Technical breakdown
Why agent-driven development changes authorisation design
Agentic developer workflows differ from traditional automation because the actor can decide when to call a tool and what to do with the result inside the session. That means the old assumption that access is provisioned for a known human task no longer holds. If a workflow can create code, retrieve data, and trigger side effects without a fixed human sequence, authorisation must be evaluated at runtime, not only at provisioning. In practical terms, the security model has to constrain the agent's execution environment as tightly as the credentials it can reach.
Practical implication: treat agent access as a runtime authorisation problem, not just a developer productivity feature.
Why sandbox boundaries must cover both inbound and outbound paths
A sandbox reduces risk only if it blocks both read access to sensitive state and unintended egress to external systems. Preventing access to production secrets is necessary, but not sufficient, because an agent can still make outbound calls to systems it should not touch. In developer workflows, the dangerous pattern is a partial boundary: untrusted code is contained locally, yet the same code can still act broadly over APIs, SaaS tools, or internal services. The control is the combination of isolation, authorisation, and network-aware policy.
Practical implication: validate both data access and outbound request policy before allowing agent execution in shared environments.
What just-in-time authorisation changes for developer identity
Just-in-time authorisation replaces standing credentials with task-scoped access that is evaluated when the request occurs. In developer workflows, that matters because API keys, environment variables, and copied tokens often outlive the task and inherit broader permissions than the agent actually needs. JIT changes the governance question from who permanently owns the credential to what the runtime is allowed to do right now. For non-human identities, that sharply reduces the blast radius of leaked secrets and makes access review less dependent on manually tracing every integration.
Practical implication: move from long-lived developer tokens to task-scoped access decisions wherever agents invoke external systems.
Breaches seen in the wild
- Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
- Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authorisation has become a design requirement, not an operational cleanup task. This article shows that AI-assisted development collapses the old separation between building software and governing access to it. When agents can call tools inside the workflow, the control point moves to architecture time, because permissions granted later arrive too late to shape behaviour. Practitioners should treat access design as part of the build system, not the post-build review.
Ephemeral execution exposes the limits of standing access models. The article's example of API keys, account tokens, and shared links shows how quickly inherited permissions can outrun the intended use case. That is classic NHI risk, but the sharper point is that developer convenience now creates machine identities and delegated access paths without a durable ownership model. The field needs to stop assuming that human workflow design can safely govern machine-paced execution.
Secure-by-default must now include tool invocation and egress control. It is no longer enough to keep an agent away from production secrets if the same agent can still speak to external systems or internal APIs without context-specific approval. Ephemeral credential trust debt: credentials that are easy to paste into a workflow accumulate governance debt the moment they outlive the task they were meant to support. Practitioners should design for narrow, contextual authority from the first integration.
Just-in-time access only works if the runtime boundary is real. The article makes clear that JIT is not a cosmetic replacement for permanent credentials. If the agent, sandbox, or workflow can carry permissions across multiple systems without revocation pressure, the organisation has only renamed standing privilege. The practical conclusion is to align access scope, runtime isolation, and revocation semantics before opening AI development to broad internal use.
Developer workflows are becoming the first mainstream proving ground for agentic identity governance. This matters because the same patterns will spread from code generation into internal operations, support automation, and business workflows. The organisations that learn to govern agent access now will have a working model for future autonomous and semi-autonomous systems. The practitioner task is to normalise this governance pattern before it is inherited by broader AI adoption.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Zero Trust for AI Agents
What this signals
Ephemeral credential trust debt: once credentials are copied into AI-assisted workflows, the organisation inherits a governance problem that looks temporary but behaves like standing access. The better control is issuance-time restraint, not post-hoc cleanup.
Developer teams now need policy at the same layer where code generation happens. If access control is still treated as a downstream IAM ticket, agentic workflows will keep outrunning the review process and expanding the number of unowned access paths.
Only 44% of developers are reported to follow security best practices for secrets management, according to the State of Secrets in AppSec. That gap matters more when AI agents can operationalise those weak habits at machine speed.
For practitioners
- Define sandboxed execution boundaries for agents Block access to production secrets, environment variables, and sensitive configuration by default, and require explicit policy for any outbound requests the agent makes.
- Replace standing developer tokens with task-scoped access Issue credentials only for the task at hand, so agentic workflows do not inherit broad permissions that survive beyond the intended use case.
- Inventory where developers paste reusable secrets Find API keys, account tokens, SSH keys, and environment variables embedded in apps, scripts, and sandboxes before they become shared access paths.
- Gate outbound tool calls by destination and purpose Require policy checks for who an agent may talk to, what data it may send, and which service capacity it is allowed to use.
Key takeaways
- AI-assisted development changes the identity boundary around software creation, so authorisation has to be designed into the workflow rather than patched in later.
- Standing developer credentials are a poor fit for agentic workflows because they widen blast radius, complicate revocation, and hide who or what actually used the access.
- Sandboxing, outbound policy, and just-in-time access only work when they are enforced at the point of execution, not as optional developer discipline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address 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 |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic workflows here depend on inherited permissions and tool-calling authority. |
| Recommendation — Limit agent privilege paths and bind each tool call to context-specific authorisation. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centers on agents and workflows inheriting broader access than needed. |
| NHI-07 — Long-Lived Secrets | The discussion explicitly warns against persistent API keys, tokens, and environment variables. | |
| Recommendation — Reduce overprivileged non-human identities by scoping access to task and runtime context. Replace long-lived secrets with short-lived credentials tied to a specific use case. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and revocation are central to the article's JIT access argument. |
| Recommendation — Apply authenticator management to rotate and retire credentials that outlive the task. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Leaked or inherited credentials enable the access and movement path described in the workflow example. |
| Recommendation — Map inherited token exposure to credential access and lateral movement detection paths. | ||
Key terms
- Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
- Sandboxed Execution: Sandboxed execution is a restricted runtime that limits what an agent can see, change, or call. For NHI governance, sandboxing is a containment control, not a full security program, because identity scope, mounts, secrets, and generated code can still create abuse paths inside the sandbox.
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
- Inherited Permissions: Inherited permissions are access rights passed from the authorizing user or application to a connected integration. They become risky when the granted scope is broader than the integration needs, because the downstream app can retain high privilege long after the original business need has changed.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org