Topic starter
10/06/2026 10:53 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by 1Password: “Vercel’s Tom Occhino on why access control is product architecture”.
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.
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.
Q: How do organisations know whether sandboxing is actually reducing AI agent risk?
A: They test for what happens after a breakout.
Practitioner guidance
- 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.
Bottom line: AI-assisted development changes the identity boundary around software creation, so authorisation has to be designed into the workflow rather than patched in later.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
12/06/2026 4:37 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent access control shifts left in developer workflows
This post was modified 3 days ago by NHI Mgmt Group