TL;DR: Cursor and Oasis are framing agentic IDE security around just-in-time, policy-based control, because agent actions now execute commands, call MCP tools, and touch internal systems in ways that create audit and approval gaps, according to Oasis Security. The security problem is no longer autocomplete, it is governing runtime execution before developer velocity turns into untracked access drift.
Editorial analysis by NHI Mgmt Group, based on content published by Oasis Security: “Oasis x Cursor: Governing Agentic Execution in the IDE”.
Key questions
Q: What breaks when agentic IDE tools are allowed to act with standing access?
A: Standing access breaks the assumption that a human reviewer can evaluate privilege before use.
Q: When does just-in-time access help most for AI agents?
A: JIT access helps most when agent tasks are episodic, high-risk, or difficult to predict in advance.
Q: What are the signs that agentic execution is getting out of control in the IDE?
A: Common warning signs are unapproved tools appearing in workflows, weak visibility into which MCP servers were used, copied tokens or workarounds, and missing approval records for high-risk actions.
Practitioner guidance
- Define runtime policy for agent actions Map allow, warn, step-up, and deny decisions to the specific agent actions that can execute commands, call MCP tools, or touch internal systems.
- Inventory approved MCP tools and endpoints Treat each MCP server as a governed access path and require explicit onboarding for unknown tools before they are reachable by an IDE agent.
- Move developer access to task-scoped issuance Replace broad standing access with ephemeral permissions that expire at task completion so agent privileges do not persist beyond the work being performed.
Bottom line: Agentic IDEs change the problem from code assistance to governed execution, which means access decisions must happen at the moment of action.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Agentic IDEs collapse the assumption that access can be governed after execution begins. The article shows that agent actions happen inside the workstream, not after it. That means approval, scope, and audit all have to be decided while the action is still live. For identity governance, this is a structural change, because the control point moves from session review to runtime decisioning.
A few things that frame the scale:
- 59% of organisations say they lack viable alternatives to standing privileged access for NHIs and AI agents, according to Delinea research.
A question worth separating out:
Q: What should security teams do when AI agents need access to tools and data?
A: Security teams should treat AI agents as runtime access actors and separate them from static machine identities. Limit tool scope, define approval gates, and require explicit revocation triggers for sessions and delegated access. The goal is to prevent broad runtime behaviour from inheriting static privileges.
👉 Read our full editorial: Governing agentic execution in the IDE needs AI zero trust