Skip to content

concepts

Intended Documentation

Authority Runtime Pipeline

How Intended verifies intent, evaluates policy, issues Authority Tokens, and enforces No Token, No Action.

intermediate8 min readimplemented

Authority Runtime Pipeline#

The authority runtime pipeline is the core execution path within Intended. Every request follows the same sequence: define intent, interpret it, verify it, grant authority, and execute only when a valid Authority Token is present. This page describes each stage, the data that flows between them, and the guarantees the pipeline provides.

Pipeline Overview#

The pipeline has six stages, executed in strict order:

  1. Intent submission — the caller describes the action it wants to take
  2. Intent interpretation — the Large Intent Model maps that action into structured intent
  3. Capability resolution — the Enterprise Capability Engine verifies the enterprise context
  4. Authority evaluation — the runtime evaluates the verified intent against the active policy set
  5. Authority Token issuance — if permitted, the runtime produces a signed Authority Token
  6. Enforcement — the downstream service verifies the token before executing the action

Each stage either succeeds and passes its output to the next stage, or fails and returns a structured error to the caller. There is no partial success — the pipeline is atomic from the caller's perspective.

Info

The pipeline operates within a single tenant's trust boundary. Cross-tenant requests are rejected before reaching the first stage. See Tenant Trust Boundary for details.

Stage 1: Intent Submission#

An intent is a structured request that describes what an agent or service wants to do. The caller submits the intent to the runtime's evaluation endpoint.

Intent Structure#

An intent contains:

FieldDescription
actionThe operation being requested (e.g., read, write, execute)
resourceThe target resource identifier (e.g., customer:record:12345)
subjectThe identity of the requesting entity, sourced from the caller's authentication context
contextOptional key-value metadata providing situational context (e.g., environment, urgency level)
tenant_idThe tenant scope for the evaluation

Example Intent#

json
{
  "action": "read",
  "resource": "customer:record:12345",
  "subject": {
    "type": "ai-agent",
    "id": "agent:support-bot-v3",
    "delegated_by": "user:operator-jane"
  },
  "context": {
    "environment": "production",
    "workflow": "ticket-resolution",
    "urgency": "normal"
  },
  "tenant_id": "tenant_acme"
}

Input Validation#

Before the intent reaches policy evaluation, the runtime validates:

  • All required fields are present and well-formed
  • The tenant_id matches the caller's authenticated tenant
  • The subject identity is recognized within the tenant's identity registry
  • The resource identifier conforms to the tenant's resource naming schema

If validation fails, the runtime returns a 400 response with specific field-level errors. No policy evaluation occurs.

Stage 2: Intent Interpretation#

This is where a raw action becomes legible as structured intent.

The Large Intent Model maps the action into an Intent Object using the Open Intent Layer. Instead of only capturing what tool was called, the runtime captures what the action is intended to do, which systems it affects, and which risk signals matter for downstream verification.

Stage 3: Capability Resolution#

The Enterprise Capability Engine maps the Intent Object to the enterprise capability context. This answers whether the action belongs to a valid business capability boundary before the authority layer decides whether it should execute.

Stage 4: Authority Evaluation#

This is where the authority decision is made. The policy engine loads the tenant's active policy set and evaluates the verified intent against it.

How Evaluation Works#

Load the active policy set

The engine retrieves all policies that are currently in active status for the tenant. Policies are versioned — the engine always uses the latest active version of each policy. The specific version numbers are recorded for auditability.

Match applicable policies

Not every policy applies to every intent. The engine filters to the subset of policies whose scope matches the intent's action, resource, and subject. A policy matches if its scope is equal to or broader than the intent's specifics.

Evaluate conditions

Each matching policy may have conditions — additional constraints that must be satisfied. Conditions can reference the intent's context fields, time-of-day, or other environmental factors. The engine evaluates all conditions for each matching policy.

Resolve the decision

If multiple policies match, the engine resolves them using a deterministic precedence model:

  • Explicit deny takes precedence over any allow.
  • Among allows, the most specific policy wins.
  • If no policies match at all, the default decision is deny (fail-closed).

Record the evaluation

Regardless of outcome, the engine records the full evaluation trace: which policies were considered, which matched, which conditions were evaluated, and what the final decision was. This trace is stored in the audit log.

Fail-Closed Default#

Warning

The policy engine defaults to deny when no policies match a given intent. This fail-closed behavior ensures that the absence of an explicit policy never results in unauthorized access. You must define policies that explicitly permit the actions your agents need to take.

Evaluation Performance#

Policy evaluation is designed to complete within single-digit milliseconds for typical policy sets. The engine pre-indexes policies by action and resource prefix to avoid scanning the full policy set on every request. For tenants with hundreds of policies, the engine maintains an in-memory policy index that is refreshed when policies are updated.

Stage 5: Authority Token Issuance#

When the policy engine returns an allow decision, the runtime issues an Authority Token. This token is the cryptographic proof that the action was verified and authorized.

What the Runtime Produces#

The runtime returns a response containing:

json
{
  "decision": "allow",
  "token": "eyJhbGciOiJFUzI1NiIs...",
  "metadata": {
    "evaluated_at": "2026-03-08T14:30:00.123Z",
    "policies_evaluated": ["pol_read_access", "pol_agent_scope"],
    "policy_versions": {"pol_read_access": 3, "pol_agent_scope": 7},
    "token_expires_at": "2026-03-08T14:35:00.123Z",
    "trace_id": "trace_abc123"
  }
}

Token Binding#

The Authority Token is bound to the specific intent that was evaluated. It cannot be reused for a different action, resource, or subject. The token encodes:

  • The Intent Object derived from the original action
  • The subject identity
  • The tenant context
  • The evaluation timestamp and expiry
  • A signature produced with the tenant's signing key

For the complete token structure and verification process, see Authority Token Model.

Denial Responses#

When the policy engine returns a deny decision, no token is issued. Instead, the runtime returns a denial response:

json
{
  "decision": "deny",
  "reason": "policy_denied",
  "details": {
    "policy": "pol_production_write_restriction",
    "policy_version": 5,
    "condition_failed": "requires approval:manager",
    "trace_id": "trace_def456"
  }
}

The denial response includes enough detail for the caller to understand why the action was denied without exposing the full policy definition. The trace_id can be used by operators to inspect the full evaluation trace in the audit log.

Stage 6: Enforcement#

Enforcement happens outside the runtime itself. The calling service is responsible for presenting the decision token to the downstream system, and the downstream system is responsible for verifying it.

Enforcement Flow#

Caller receives the token

After a successful evaluation, the caller holds a signed decision token.

Caller presents the token

When executing the authorized action, the caller includes the decision token in the request — typically in an Authorization header or a dedicated X-Decision-Token header.

Downstream service verifies

The receiving service verifies the token by checking the cryptographic signature against the tenant's public key, validating that the token has not expired, and confirming that the token's encoded action and resource match the request being made.

Action executes or is rejected

If verification succeeds, the service executes the action. If verification fails, the service rejects the request. The service should not fall back to alternative authorization — a failed token verification is a hard stop.

Tip

Token verification is a local operation. The downstream service does not need to call back to the Intended runtime — it only needs the tenant's public key, which can be cached and rotated on a schedule. This keeps enforcement fast and avoids introducing the runtime as a single point of failure in the execution path.

Enforcement Responsibilities#

The Intended runtime issues tokens and provides verification libraries, but enforcement is the responsibility of the service consuming the token. Intended provides SDKs and middleware that handle verification, but the decision to reject unauthorized requests must be wired into the consuming service's request handling.

Pipeline Guarantees#

The authority runtime pipeline provides the following guarantees:

  • Atomicity — every intent evaluation either produces a token or a denial. There are no partial or ambiguous outcomes.
  • Determinism — the same intent evaluated against the same policy set produces the same decision. There is no randomness or non-deterministic behavior in the pipeline.
  • Auditability — every evaluation is recorded with full context, regardless of outcome. The audit trail links intent, policy versions, decision, and token together.
  • Fail-closed — the absence of a matching policy results in denial. The system never defaults to allowing an action.
  • Tenant isolation — the pipeline operates entirely within a single tenant's trust boundary. Policies, keys, and tokens from one tenant are invisible to another.