CybersecurityHQ — CISO Deep Dive
In partnership with:
Opal Security — The programmable access platform bridging policy intent and enforcement, combining AI with CISO context and an engineer's precision.
Smallstep — Hardware is the new MFA. Start with Wi-Fi, then extend device identity with ACME DA across apps and infrastructure—only trusted devices get access.
LockThreat — AI-powered GRC that replaces legacy tools and unifies compliance, risk, audit and vendor management in one platform.
CHQ DEEP DIVE ID: CHQ-DD-2026-05-23
AUDIENCE: CISO / SECURITY LEADERSHIP / IDENTITY ARCHITECTS / APPLICATION SECURITY / DEVSECOPS / PLATFORM ENGINEERING / AI SECURITY
TOPIC: Mutable Authority Signal Reliance and Delegated Authorization Failure in AI Agent Runtime Frameworks
CYBERSECURITYHQ Deep Dive 23 May 2026
The Authorization Decision Was Delegated to the Entity Being Authorized
Three AI agent frameworks. Three distinct vulnerabilities. Three weeks. The failure class was consistent in each case: authorization decisions depended on mutable, absent, or attacker-influenced trust signals rather than assertions derived from independently verifiable sources. In all three, attackers able to satisfy each system's prerequisite access conditions could influence or bypass the privilege decision.
Three independent disclosures in three weeks do not prove a universal authorization doctrine. They indicate recurring reliance on mutable, absent, or improperly verified authority signals. The repetition across independently developed frameworks suggests something about where AI agent security review has been focused, and where it has not.
The Three Cases
Cline is a widely deployed AI coding agent running inside VS Code. A researcher at Oasis Security found that Cline's local WebSocket server accepted connections from any browser origin without validation. A malicious website the developer visited could send commands to the Cline agent running on that developer's machine. The agent would execute those commands with whatever permissions it had been granted: access to the codebase, terminal execution, file operations. CVSS 9.7.
The failure: the agent's execution surface accepted instruction from an unverified origin. No check confirmed that the caller had any legitimate relationship with the agent or the developer who deployed it.
PraisonAI is an open-source multi-agent orchestration framework. Its legacy Flask API server had AUTH_ENABLED = False hardcoded in the source. The endpoint that triggers agent workflows required no authentication token, no session, nothing. Any network-reachable caller could invoke the agent's full operational capability. CVSS 7.3.
The failure: the access control switch was off by default and stayed off unless an operator explicitly changed it. Most operators did not know it existed.
OpenClaw has over 180,000 deployed instances. In a four-CVE chain disclosed by Cyera researchers, the most structurally significant issue is CVE-2026-44118. Owner context in the OpenClaw MCP loopback runtime was derived from spoofable request metadata rather than securely bound to authenticated identity. A local process able to operate within a valid authentication context could escalate to owner-level control over agent runtime configuration, scheduling, and capability access.
The fix: bind privilege determination to authenticated identity, separating owner and non-owner tokens at the authentication layer rather than accepting ownership context from request metadata.
The authorization decision was delegated to the entity being authorized.
The Pattern Underneath
These three vulnerabilities have different mechanisms. Cline's failure is a cross-origin trust boundary problem. PraisonAI's is a misconfigured default. OpenClaw's is an explicit caller-influenced privilege assertion derived from spoofable metadata. The more accurate unifying description: in all three cases, the authorization decision was made using information the attacker could influence.
In Cline's case, the origin trust boundary was not validated. In PraisonAI's, access was granted without requiring any independently verified identity. In OpenClaw's, ownership context could be manipulated through request metadata rather than being bound to authenticated identity.
The common factor is not that authentication was absent. OpenClaw required a valid bearer token. The common factor is that the authorization decision -- who is allowed to do what -- was resolved using a mutable or attacker-influenced signal rather than being derived from a verification source the caller could not manipulate.
The attacker position differs across these cases: browser context, network caller, local process. The question the attacker asked is identical: can I reach the execution surface and influence what authority the agent believes I have?
These cases arise from distinct root causes; the commonality is not implementation class but dependence on mutable or insufficiently verified authority signals.
A Problem With a Precise Name
Norm Hardy described a related failure class in 1988: the confused deputy problem. A FORTRAN compiler had been granted access to billing records for audit purposes. A user discovered they could invoke the compiler in a way that caused it to write output to the billing file. The compiler was not malicious. It had legitimate access. It was tricked into exercising that access on behalf of someone who did not have it.
The confused deputy framing is a useful lens for understanding aspects of these failures, particularly where agents exercise legitimate authority on behalf of improperly verified principals. It applies most cleanly to OpenClaw, where an agent with real authority was directed through spoofable metadata. It applies loosely to Cline, where cross-origin abuse caused privileged execution via a trusted agent. It fits PraisonAI least precisely -- missing access control and insecure defaults are their own failure class, and calling them confused deputy would be interpretive overreach.
What the framing captures across all three is the central question: not whether the agent authenticated the caller, but whether the agent verified whose authority it is actually operating under.
What Agents Actually Hold
AI agents collapse the distance between authorization errors and operational impact. A broken privilege check in a web application typically exposes application data. A broken privilege check in an AI agent framework exposes execution capability attached to source code, credentials, infrastructure, and deployment systems.
An AI coding agent on a developer's machine typically holds read and write access to a codebase, terminal execution capability, environment variables containing cloud credentials, SSH keys, API tokens, and files containing secrets developers have not explicitly protected. That access profile is reasonable for a developer's own machine. Exposing it to any website a developer visits, or any network-reachable caller, or any local process that can influence request metadata -- that is not a web application authorization failure. It is an authority delegation failure.
For organizations running AI agents in CI/CD pipelines, the scope extends to production deployment authority, secrets manager access, and cloud IAM permissions. An authorization failure there is not a developer environment problem. It is whatever the pipeline is authorized to reach.
The agent inherits authority. Authorization failures determine who inherits it next.
Why Detection Fails
The detection problem is the same across all three cases: a successful attack looks like normal agent activity.
When OpenClaw's owner context is spoofed, the agent receives what appears to be a legitimate owner request. It configures itself for a different task. It accesses services it was authorized to access. It runs commands within its normal operational envelope. The four-CVE chain proceeds: malicious plugin gains a foothold, race condition exposes credentials, owner context escalation grants runtime control, second race condition plants a backdoor. At each stage, the agent performs actions within its normal operational scope. Execution-layer detection may not surface any of it, because there is nothing anomalous about the execution itself.
Behavioral anomaly detection alone is often insufficient for this threat class precisely because the mechanism of attack causes the agent to behave legitimately. Traditional anomaly detection looks for activity outside the normal envelope. Confused deputy attacks operate inside it with a different principal.
Detection for this class happens at the authority chain layer: what called this agent, through what path, with what authority, and can that authority be verified independently of the caller's assertion? That is a different instrumentation requirement than most organizations have built for their AI agent deployments.
The Governance Implication
AI agent security is a delegated authority problem. It is being treated as an application security problem. That distinction determines what questions the security function asks.
Application security asks: did we authenticate the caller? Did we validate the input? Is the endpoint protected?
Delegated authority asks: whose authority is this agent actually operating under? Can that be verified at the point of execution? What is the chain of custody from the human who granted the authority to the runtime that is exercising it?
A review that stopped at credential presence could miss all three. OpenClaw had credentials. The question it failed to answer was whether the ownership context in the request actually represented the authority of the authenticated principal.
Organizations increasingly inventory access profiles, but runtime authority chains remain less visible -- what called the agent, through what path, and whether the authority being exercised can be traced back to the principal who granted it. At the framework level, fixes differ by implementation: bind privilege to authenticated identity rather than caller-controlled assertions, validate trust boundaries explicitly, and avoid exposing privileged execution surfaces without authentication enabled. The fix at the organizational level is harder: treat AI agent deployments as delegated authority instruments and govern them accordingly.
Capability-oriented models are one approach to mitigating confused deputy failures, moving authority into the invocation itself rather than re-verifying it at each call. Broad adoption of capability-oriented security models across AI agents appears distant. In the interim, the industry will secure these systems the way it secured cloud credentials and IoT interfaces -- reactively, one disclosure at a time, as researchers find what the defaults allow.
The question is whether the access profiles sitting behind AI agents during that interval are sized for the security posture those agents actually have.