The question at hand
Your team just deployed a coding assistant that can read private repositories, call cloud APIs, and execute shell commands. The vendor's setup guide suggests granting it persistent access to your development environment. Your security team disagrees, warning against it. Your engineering lead argues that just-in-time access will disrupt workflows.
This is not a hypothetical tradeoff. It's the central tension in AI agent security, and the decision will determine whether your agents enhance productivity or become security risks.
The core question: Should AI agents have standing privileges that persist beyond individual tasks, or should every action require just-in-time authorization that expires once the task is complete?
The case for standing privileges
The argument for persistent access is straightforward: AI agents can't wait for human approval at every step. If your agent needs to query a database, call an API, read a configuration file, and write results back to storage, requiring manual approval at each step defeats the purpose of automation.
A January 2026 CyberArk survey found that 91% of security practitioners reported at least half of their privileged access remains always-on and persistent. This isn't due to ignorance of the risks but because operational needs often make persistent access the only viable option. Delinea's 2026 Identity Security Report found that 74% of organizations say standing access for nonhuman identities and AI agents is necessary to meet uptime expectations, while 59% say they lack viable alternatives.
The engineering case strengthens when considering workflows that span hours or days. For example, an agent monitoring pull requests, running security scans, and posting results to a tracking system would require complex credential management if it needed to reauthenticate every 15 minutes. For many teams, this complexity outweighs the security benefits.
Most AI agent platforms ship with standing privileges as the default configuration. This is not accidental; it's the easiest path for vendors and customers. Organizations with mature just-in-time controls have an advantage, but agent security also requires discovery, workload and agent identity separation, constrained tool permissions, ownership, continuous monitoring, and a reliable offboarding path. Building all of that takes time most teams don't have.
The case for just-in-time access
The security argument against standing privileges became undeniable in early 2026. In June, the Sysdig Threat Research Team documented the first end-to-end AI-agent-driven ransomware operation. The agent exploited an unpatched vulnerability in Langflow (CVE-2025-3248), accessed a MySQL database using a known bypass (CVE-2021-29441), harvested API keys for OpenAI, Anthropic, DeepSeek, and Gemini, collected cloud credentials for Alibaba, Tencent, AWS, Google, and Azure, and encrypted 1,342 Nacos configuration records. This entire process occurred autonomously, with no human intervention beyond the initial breach.
This incident didn't require a zero-day exploit. It needed an unpatched system, standing credentials, and an agent capable of autonomous decision-making. When an agent inherits permissions from its host environment, a single compromised credential can become a skeleton key.
Similar patterns appeared in other disclosures. Microsoft found that a malicious web page could access a local MCP service inside AutoGen Studio and spawn processes on the host. Wiz Research discovered that Amazon Q Developer would auto-load and execute MCP configuration files from any opened workspace, granting an agent full AWS environment access. Cato AI Labs found a zero-click prompt injection could escape Cursor's command sandbox entirely. Different codebases, different companies, but a related control failure: The agent inherits permissions from its host environment, trusting whatever configuration it finds.
Just-in-time access limits the damage. If credentials expire after a task, an attacker compromising an agent mid-workflow gets a narrow window of access, not persistent control. Requiring fresh authorization for each action provides an audit trail showing what the agent actually did.
The discovery problem exacerbates this issue. Verizon's 2026 Data Breach Investigations Report found that employee use of unapproved AI tools tripled to 45% of the workforce. Saviynt's CISO AI Risk Report found that 75% of CISOs have already discovered unsanctioned AI tools in production. Netwrix's 2026 Data and Identity Security Report found that 76% of organizations don't fully govern or monitor nonhuman identities, including AI agents. Shadow agents with standing privileges create an attack surface you can't even inventory.
Where practitioners actually land
The same CyberArk survey that found 91% persistent access also found that only 1% of security practitioners have fully implemented just-in-time privileged access. Delinea found that organizations are more than twice as likely to use long-lived credentials (34%) as modern just-in-time authorization (16%).
This gap shows where most teams are: They know standing privileges are a problem but haven't operationalized the alternative. The result is a compromise that satisfies neither security nor engineering: Agents get persistent access to some systems but not others, with boundaries determined more by implementation difficulty than risk profile.
Our take
Standing privileges for AI agents are a technical debt you're taking on consciously or by default. The question isn't whether to eliminate them entirely. It's whether you're willing to do the work to make just-in-time access operationally viable.
If you can't implement just-in-time authorization today, treat standing privileges as a transitional state with clear boundaries. Review agents connected to production databases, sensitive data, and secrets. Ensure guardrails evaluate the command that will actually run after shell processing, not just the raw input. Identify nonhuman identities that no one can account for. Scrutinize agents that consume untrusted content and then either send data outside the company or invoke a privileged tool.
The OWASP Top 10 for Agentic Applications maps every incident in this piece: Identity and Privilege Abuse (ASI03), Tool Misuse and Exploitation (ASI02), Agentic Supply Chain Vulnerabilities (ASI04), and Unexpected Code Execution (ASI05). The framework exists, the incidents are public, and the governance gap is now quantified.
The teams that close this gap will stop treating agent access as a deployment detail and start treating it as an identity lifecycle problem, with the same rigor they apply to human privileged access. Most of the work starts with access that's been left in place because nobody had a reason to revisit it. That includes credentials with no expiry, agents whose original owner has moved on, and tools that can run commands or pull data with little visibility into what happens next.
You may be able to find much of this in systems you already operate. IAM and PAM records, endpoint logs, secrets tooling, and cloud inventories won't tell the whole story, but they can show you access that has no clear purpose or owner.
