Authorizing agent workflow steps, not just agent identity

What is this?

On July 20, 2026, a group of researchers posted a paper to arXiv (in the cs.CR / cryptography-and-security category) that reframes a problem most agent stacks get wrong. As enterprise and government systems turn into “language-based, tool-using and increasingly autonomous infrastructures,” the authors argue, the security model inherited from classic key management no longer fits. A conventional key management service authenticates who is allowed to invoke a cryptographic primitive — it verifies an identity and then hands over the capability. What it does not do is decide which workflow step an authenticated caller is allowed to take at runtime. That gap is exactly where an agent gets dangerous: an agent that passed every identity check can still be steered, by direct or indirect prompt injection, into an action that is perfectly valid for its identity yet violates what the user actually wanted. The paper’s contribution is a design that tries to close the gap — a governance layer sitting between the model and the privileged tools it can reach.

How it works

The core observation is a distinction that is easy to blur in agent design: authentication is not authorization, and per-agent authorization is not per-step authorization.

Most deployed agents bind privilege to identity. The agent (or its service account) holds a token, an API key, or a signing capability; once the agent is authenticated, any action it emits inherits that privilege. The model itself decides which tool to call and with what arguments, based on natural-language context it has read — user messages, retrieved documents, tool outputs, inter-agent messages. Because that context is the very channel an attacker controls in a prompt-injection attack, the decision to act can be corrupted while the credential used to act remains completely legitimate. Identity checks pass. Intent is violated. Nothing in a “who are you” check can tell the two apart.

The paper’s proposed answer is called Neural Cryptographic Services (NCS) — described as an active security governance plane, built on a neural-symbolic design, and interposed between LLM agents and the privileged tools they invoke. The framing to take away, independent of the specific implementation, is architectural: authority should be bound to the step — a specific action, in a specific workflow, consistent with the user’s stated intent — rather than to the persistent identity of the agent. A control point that mediates every privileged call can evaluate whether this action is authorized now, instead of assuming that an authenticated agent is a trusted agent. No exploit is reproduced here; the value is the model of the problem and the placement of the defense.

Why it matters

This is the same failure mode that keeps surfacing under different names across agent security research. Data flow is treated as authority; an instruction that arrives through a document or a tool result is obeyed as if the user had typed it; a coding or browsing agent with a broad token does something out of scope but “in policy.” The paper’s contribution is to name the root cause cleanly — the authentication layer is agnostic to workflow intent — and to argue the fix belongs in a dedicated authorization plane rather than in the model’s own judgement.

It matters most where the blast radius is largest: agents wired into key management, payments, cloud control planes, or government and enterprise back-ends, where a single intent-violating action that satisfies identity checks can move money, rotate a secret, or change a record. For those systems, “the agent authenticated successfully” is not a safety property. Prompt injection remains the top-ranked risk in OWASP’s LLM application guidance precisely because it converts a trusted, authenticated agent into an attacker-steered one without ever breaking a credential.

Defenses

The practical lesson is to stop treating an agent’s identity as a proxy for its authorization to act. Put a deterministic control point between the model and any privileged tool, and have it authorize actions at the granularity of the workflow step — not once at login. Concretely, that means binding each privileged call to an explicit, user-anchored intent and to the step in the plan it belongs to, and rejecting calls that satisfy identity but not intent, an approach echoed in concurrent work on deterministic pre-action authorization and authenticated agentic workflows. Keep the enforcement outside the model: a policy the LLM can be argued out of is not a control. Scope credentials to the narrowest capability and shortest lifetime the step needs, so that even a hijacked-but-authenticated action has a small reach. Treat retrieved documents, tool outputs and inter-agent messages as untrusted input that can propose actions but never silently authorize them. And log the authorization decision, not just the tool call, so that a mismatch between stated intent and executed action is auditable after the fact. These controls compose with, rather than replace, input filtering and jailbreak defenses — the point is that when injection succeeds, the authorization plane is what stands between a corrupted decision and a privileged action.

Status

Item	Detail
Contribution	Framing + proposed governance plane for step-level agent authorization
Core claim	Authentication (“who”) does not authorize the workflow step (“which action, now”)
Threat	Direct/indirect prompt injection producing identity-valid, intent-violating actions
Proposed design	Neural Cryptographic Services (NCS) — neural-symbolic governance plane between agents and privileged tools
Placement	Deterministic control point interposed on every privileged tool call
Key date	Paper posted to arXiv on July 20, 2026

Key date: paper announced on arXiv on July 20, 2026. The design is a research proposal, not a shipping product; the durable takeaway is the architectural one — authorize the step, not the identity.