Governing agentic execution in the IDE needs AI zero trust

At a glance

What this is: This is an analysis of governing AI agent execution inside the IDE, with the key finding that policy, approval, and audit controls have to move into the action path.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agentic behaviour at runtime, not just manage credentials and recertify static access.

👉 Read Oasis Security's analysis of governing agentic execution in the IDE

Context

Agentic IDEs change the identity problem because the software is no longer only suggesting code, it is executing commands and using tools with real access. That shifts the control question from developer convenience to governable execution, especially when the agent can touch internal systems through MCP endpoints and inherited permissions.

The governance gap is straightforward: security teams can often see that an AI tool was used, but not always what tool, data, or privilege was exercised at the moment of action. That is an NHI and lifecycle issue at the same time, because the access must be scoped, attributable, and revocable for each task or session. The post frames a typical emerging enterprise pattern rather than an edge case.

Key questions

Q: How should security teams govern AI agents inside the IDE?

A: Security teams should treat IDE agents as non-human identities that need scoped permissions, runtime policy checks, and immediate revocation after task completion. Governance should sit in the execution path, not only in logging or post-incident review, so commands, MCP calls, and high-risk actions are controlled before they occur.

Q: Why do agentic IDEs create different access risks from normal developer tools?

A: Agentic IDEs create different access risks because the software can execute commands and call tools, not just assist a user. That means privilege can be exercised at machine speed, with less human oversight, and the resulting actions may blend into ordinary developer workflows unless policy is enforced at runtime.

Q: What breaks when AI agent access is broader than the task it is trying to complete?

A: When agent access is broader than the task, the identity can touch systems, data, and tools that were never necessary for the work. That expands blast radius, makes audit trails harder to interpret, and turns a useful automation into an ungoverned privilege path that security teams may only see after damage is done.

Q: How do IAM and PAM teams handle approval for high-risk agent actions?

A: IAM and PAM teams should require explicit step-up approval for production access, destructive commands, and sensitive data movement, then revoke that privilege immediately after the session. The goal is to make the agent's authority temporary, attributable, and narrow enough to survive audit and incident review.

Technical breakdown

Agentic IDE execution and MCP tool calls

In an agentic IDE, the agent is not just generating text. It can invoke commands, call MCP tools, and interact with internal systems as part of a live workflow. That creates a different trust boundary from ordinary code completion because the meaningful security event is execution, not suggestion. MCP becomes relevant because it is the path by which the agent reaches data sources and tooling. The real control question is whether those tool calls are visible, attributable, and policy checked at the point of use.

Practical implication: control agent tool invocation at execution time, not after the output has already been produced.

Cursor Hooks as an enforcement point for AI access management

Hooks create a policy checkpoint before or after agent actions in the IDE. That is technically important because it moves security away from perimeter monitoring and into the workflow where the access decision is actually made. In practice, a hook can inspect request context, identify the tool or command, and return allow, warn, step-up, or deny. This is less about telemetry alone and more about converting agent activity into a decisionable identity event. It is also the basis for audited, task-scoped access.

Practical implication: place policy checks where the agent acts, so risky commands never become unreviewed execution.

Intent-based access and ephemeral privilege for agents

The article describes intent-based access as a shift from standing privilege to scoped, temporary access tied to a task or session. That is a classic NHI pattern, but the agentic context raises the bar because the identity making the request is software that can keep working after the developer stops thinking about it. Just-in-time access only works if the request is narrow, the approval is explicit, and revocation happens immediately after completion. Otherwise, the control becomes a cosmetic layer over persistent privilege.

Practical implication: design agent access as ephemeral and task-scoped, then revoke it as soon as the session ends.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI IDE governance collapses when execution is treated as autocomplete. The article shows that the risky moment is not code suggestion but command execution, tool invocation, and internal system access. That means the control model built for human developers and static integrations is already behind the behaviour of agentic IDEs. Practitioners should treat agent actions as governed identity events, not just productivity output.

Intent-based access is a named governance shift, not a feature request. The model replaces standing access with task-scoped, ephemeral privilege that is tied to the agent's current objective. That aligns with OWASP-NHI and zero trust principles, but the important point is that the access decision has to be made at the moment of action. For IAM teams, the operational question becomes whether permissions can be bound tightly enough to intent to remain auditable.

Shadow AI in the IDE is really shadow identity in motion. The article's concern is not only unknown tools, but unknown combinations of agent, MCP server, data, and developer approval state. That combination creates attribution drift, because teams lose track of who authorised which action and under what scope. The implication is that identity governance for AI development now needs runtime visibility, not only inventory and recertification.

Agent Access Management sits at the intersection of NHI lifecycle and PAM. The article points to onboarding, scoped permissions, expiration, and auditability as the governing lifecycle for agents. That is the right framing because the access pattern is non-human, privileged, and highly temporal. Practitioners should recognise this as an NHI lifecycle problem with PAM-grade consequences, not a developer tooling experiment.

Policy enforcement inside the execution path is the control plane that AI Zero Trust requires. The article argues for allow, warn, step-up, and deny decisions at action time, which is exactly where traditional perimeter controls lose context. That matters because once the agent can call tools directly, the old assumption that security can inspect the traffic later is too weak. The field should now judge AI controls by whether they can govern action, not only observe it.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which shows how quickly governance assumptions weaken at the point of use.
• That same research shows organisations maintain an average of 6 distinct secrets manager instances, a fragmentation pattern that strengthens the case for centralised policy and audit coverage.

What this signals

Agentic IDE governance is moving from identity inventory to action governance. Once an agent can call MCP tools and execute commands, the programme boundary shifts to runtime enforcement, and teams need policies that can differentiate approved work from unbounded execution. For broader alignment, the governance model should map to the principles in the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10.

Intent-based access: temporary permissions tied to a single task or session become the right control shape for agents. The implication for practitioners is that static entitlements and delayed recertification are too slow for software that can act, delegate, and finish work faster than review cycles. Teams that want a practical NHI baseline should align this with the Ultimate Guide to NHIs , Key Challenges and Risks.

The strongest signal for security programmes is whether policy can interrupt execution before access is consumed. If a control only records what happened, it is observation, not governance. When teams start measuring denied high-risk actions, step-up approvals, and revoked session access, they are finally testing whether AI Zero Trust exists in practice rather than in presentation.

For practitioners

• Move policy into the agent execution path Place enforcement before MCP calls and command execution so the decision happens before access is consumed. Use allow, warn, step-up, and deny as explicit states for high-risk actions such as production access or destructive commands.
• Treat agent sessions as ephemeral identities Assign task-scoped access to each session, limit it to the minimum tool set required, and revoke it immediately after the task completes. Do not let a developer convenience workflow turn into standing privilege for the agent.
• Separate telemetry from governance Log agent actions, tool use, identity attribution, and data movement in a central control plane so review and response are possible after the session. Keep the logging layer distinct from the policy layer so visibility does not masquerade as control.
• Onboard MCP servers through explicit trust workflows Require approval for new tools and endpoints before agents can use them, and classify unknown or low-reputation scripts as untrusted until they pass review. This reduces shadow MCP exposure and makes supply-chain risk a governed decision.

Key takeaways

• Agentic IDEs turn code assistants into governed identity actors, so access control has to move into the execution path.
• Runtime policy, ephemeral privilege, and auditable action trails are the controls that separate safe task execution from shadow AI behaviour.
• IAM, PAM, and NHI teams should evaluate agent sessions as temporary identities, not as extensions of a developer account.

Key terms

• Agent Access Management: Agent Access Management is the discipline of governing AI agents as non-human identities with scoped permissions, lifecycle controls, and auditability. It extends identity governance into runtime execution, where the important question is not only who configured the agent, but what it was allowed to do at the moment of action.
• Intent-based access: Intent-based access is a model where permission is granted for a specific task or session rather than as standing privilege. In agentic systems, it means the scope, timing, and revocation of access are tied to the current objective, which reduces blast radius and makes delegation more defensible.
• Cursor Hook: A Cursor Hook is an execution checkpoint that runs before or after an agent action in the IDE. It can inspect context, log activity, and enforce policy decisions, turning tool use and command execution into governed events instead of invisible developer-side automation.
• Shadow AI: Shadow AI is the use of AI systems, tools, or agents that security teams have not discovered, approved, or governed. In practice, it creates identity drift because the organisation loses track of what software is acting, which tools it can reach, and whether any access has been properly scoped.

Deepen your knowledge

Agentic IDE governance and just-in-time access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building policy controls for AI agents inside developer workflows, it is worth exploring.

This post draws on content published by Oasis Security: Oasis x Cursor: Governing Agentic Execution in the IDE. Read the original.