Skip to content
Go back

Agent Intent Authorization: Plan-Before-Execute Security for AI Agents

This post was originally shared on LinkedIn.

Table of contents

Open Table of contents

The Gap That Remains After JIT Authorization

Just-In-Time (JIT) authorization is a meaningful improvement over standing privilege. Requiring a Passkey approval at the moment of a sensitive action eliminates the “authenticate once, act freely” problem.

But JIT authorization operates at the individual action level — each sensitive operation triggers a separate approval. This works for discrete, high-risk actions. It does not address the broader question:

Should the agent be doing all of this in the first place?

When an agent executes a multi-step task, the sequence of actions collectively forms an intent. JIT authorization approves individual steps. Agent Intent Authorization approves the plan.

What Is Agent Intent Authorization?

Agent Intent Authorization introduces a plan-before-execute security layer for agentic systems.

The core principle:

Agents earn the right to act. They do not assume it.

Before an agent executes anything, it must surface its complete execution plan. The user reviews the full scope of intended actions — what will be accessed, modified, created, or deleted — and approves with a single device-bound Passkey gesture.

That approval creates a cryptographically signed intent token that restricts all subsequent actions to the declared scope. Any action outside the approved plan is blocked.

The Five-Step Flow

1. User Describes Task

The user provides a natural language request to the agent: “Rotate all service account keys for the production environment and update the relevant secrets.”

2. Agent Generates Execution Plan

Rather than acting immediately, the agent produces a structured execution plan — a complete declaration of all intended operations, including the specific resources, actions, and execution context.

Intent Plan:
- List service accounts in project: prod-env         [READ]
- Rotate key for: svc-api@prod-env.iam               [WRITE]
- Rotate key for: svc-worker@prod-env.iam            [WRITE]
- Update secret: API_KEY in vault/prod               [WRITE]
- Update secret: WORKER_KEY in vault/prod            [WRITE]

3. User Reviews Intent

The plan is presented inline — inside the AI assistant or CLI — without browser redirects or context switching. The user sees exactly what the agent intends to do before anything happens.

4. Passkey Approval

A single device-bound Passkey gesture approves the entire plan. The authenticator generates a signed assertion cryptographically binding the approval to the exact declared scope.

This produces a Scope-Bound Cryptographic Proof: a signed intent token carrying the full approved execution context.

5. Scoped Execution

Every subsequent action the agent takes is verified against the signed intent token. Actions that match the approved plan proceed. Actions outside the declared scope are blocked — even if the agent attempts them.

The Subject-Action-Resource-Context (SARC) Model

Intent Authorization uses a structured SARC model to represent each approved operation:

FieldDescription
SubjectThe agent identity (workload + delegated user context)
ActionThe specific operation (read, write, delete, invoke)
ResourceThe target resource (service account, secret, API endpoint)
ContextExecution environment, session binding, temporal scope

Each entry in the execution plan maps to a SARC tuple. The signed intent token encodes all approved tuples. The Policy Enforcement Point validates every action against this token at runtime.

A Composable Three-Layer Stack

Agent Intent Authorization is designed to compose with existing authorization layers, not replace them:

Layer 1 — OAuth Security
  Baseline access control, token validation, scope enforcement

Layer 2 — Intent Authorization  ← this layer
  Plan approval, cryptographic scope binding, execution governance

Layer 3 — Just-In-Time Agent Native Authorization
  Runtime step-up for high-sensitivity actions within the approved plan

This “Lego blocks” model means you can deploy the layers independently or together, depending on the sensitivity of your agent workflows. The layers are also composable with existing OAuth 2.1 infrastructure — they do not require replacing what you already have.

Built on Open Standards

The framework relies entirely on open, interoperable specifications:

Integration with Keycloak provides identity management, workload identity issuance, and the Passkey authentication flow — all within a single, open-source IAM platform.

Why This Changes the Security Model

Traditional authorization answers: “Is this action permitted?”

JIT Authorization answers: “Is this specific action permitted right now, with human approval?”

Agent Intent Authorization answers: “Is this entire plan within the scope that was explicitly and cryptographically approved?”

This is a fundamentally different guarantee. It eliminates an entire class of risk: agents that individually take permitted actions but collectively execute something the user never intended to authorize.

What’s Next

Agent Intent Authorization is live in the TwoGenIdentity Agent Native Authorization (ANA) framework, and is being extended to support:

If you are working on secure AI agents, MCP infrastructure, or authorization frameworks, I would welcome the opportunity to connect.


Share this post:

Next Post
AI Agents Require Runtime Authorization: Just-In-Time Passkey Approval for Sensitive Actions