What Is a Decision Token?

A decision token is a cryptographically signed, versioned record issued by a policy engine at the moment an AI agent makes a business decision. It captures what policy applied, what was authorized, when the decision occurred, and why — creating an immutable audit trail before the agent acts. The token travels with the agent's action request and is verified by a connector before any downstream system executes the action.

What a decision token contains

A decision token is intentionally compact — it contains what the connector needs to verify and enforce, not the full decision record. The full decision record is stored separately, linked by the decision ID and always retrievable for audit.

The signed token payload contains:

• Decision ID — a unique identifier that links this token to the full decision record stored in Polidex; every token maps to exactly one logged decision
• Agent identity — which AI agent made the request and initiated the interaction
• Action scope — the exact action authorized: not just "issue a refund" but "refund:order:999876:$47.50" — amount, order, and action type are cryptographically bound
• Policy version — which policy version was active at decision time; pinned at issuance so the record survives subsequent policy changes
• Decision outcome — approved, denied, or escalate
• Expiry timestamp — authorization windows are short by design, typically five minutes; the agent is expected to act within that window, not hold the authorization indefinitely
• One-time use — the token cannot be presented twice; replay is rejected at the connector

The decision record (retrieved by decision ID) contains the full context:

The token's decision ID links to a complete, immutable record that stores everything used in the evaluation: the customer attributes and order context that were presented, the authorization path showing which rules were evaluated and what thresholds applied, the data sources consulted, and the plain-language explanation of the outcome. This is what surfaces in the audit log and what a compliance reviewer reads when tracing a decision.

The separation is intentional. The token is a small, cryptographically signed claim — tamper-evident, single-use, and scoped to one action. The decision record is the rich audit artifact. Together, they give you both enforcement (the token) and traceability (the record).

How a decision token is issued

The flow is sequential and architectural. Each step depends on the previous one. The agent cannot skip any of it.

1. The agent asks for a decision.

The AI agent sends context to Polidex: customer identity, what's being requested, what order or account is involved. The agent does not apply policy itself. It asks.

2. Polidex evaluates the request.

Polidex checks the customer's eligibility, the applicable rules, any limits or thresholds, and whether the request requires human approval. This evaluation happens against the current published policy version.

3. If approved, Polidex issues the token.

The token is cryptographically signed using a private key that exists only within Polidex and is never transmitted anywhere. The signature is mathematically bound to every field in the token — the customer ID, the order reference, the exact dollar amount, the expiry time. If any field is modified after issuance, the signature becomes invalid and the connector will reject the request.

4. The agent confirms with the customer.

Polidex does not execute the action automatically when it issues a token. The agent is managing a live conversation. It communicates the decision, handles follow-up questions, and confirms the customer wants to proceed. The short expiry window exists because the agent is expected to act, not hold the authorization.

5. The connector verifies before executing.

When the agent calls the downstream system — a refund platform, a ticketing system, a CRM — it goes through a Polidex connector. The connector performs four checks: the signature is valid; the token has not expired; the token has not already been presented; the scope of the requested action matches exactly what was authorized. If any check fails, the connector rejects the request and logs the attempt. The action does not occur.

The agent never touches the downstream system directly. Its only path to execution is through the connector. The connector requires a valid token. The token requires a Polidex decision. That decision requires a request that passes your configured policy rules.

Decision tokens vs. standard authorization tokens

This is the distinction that matters for understanding why decision tokens are a different category of record.

A standard API authorization token — an OAuth token, a JWT, an API key — answers one question: is this agent allowed to make requests? It proves identity and permission scope. It does not say anything about which business policy governed a specific action, or why that action was authorized at that moment.

A decision token answers a different set of questions: What policy applied to this specific decision? What was the agent authorized to do — exactly? When? Which version of the policy was in effect?

The difference is not subtle. An OAuth token says "this agent has permission to call Shopify." A decision token says "Polidex authorized a $47.50 refund on order 999876 for this customer at 14:37:22 under refund policy version 2.3, and that authorization is valid for five minutes and one use."

Authorization tokens govern access. Decision tokens govern decisions. You need both — but they solve different problems. An AI agent that has an OAuth token but no decision token can call the system. It cannot prove what business rule authorized the specific action it took.

"It was in the system prompt" is not an audit trail. A decision token is.

How decision tokens create an audit trail

Every token Polidex issues is logged at two moments: when it is issued, and when the connector presents it for verification. The log record at each moment is immutable — it cannot be altered after it is written.

This produces a decision record that the audit trail requirement actually requires:

• Traceability — which agent, which customer, which request, at what timestamp
• Explainability — which policy rule governed the outcome, at which policy version
• Authorization — what was explicitly permitted, scoped to this exact amount, customer, and order
• Immutability — the record was written at decision time and cannot be changed; the cryptographic signature on the token makes tampering detectable
• Reproducibility — given the decision ID, any reviewer can pull the full record: inputs presented, policy version evaluated, authorization issued, connector action taken

When a compliance audit or customer dispute surfaces a decision from six months ago, the question is simple: look up the decision ID. The record shows what policy was active at that moment, what rule was applied, what was authorized, and whether the connector verified and executed the action. There is no reconstruction from conversation logs. There is no "we think the system prompt said X." There is a record.

Policy changes do not break the trail. If your refund policy changed from version 2.3 to version 2.4 in March, decisions made under version 2.3 still have their policy version pinned in their token. The audit shows what rule governed each decision at the time it was made.

If a token is presented and rejected — because it expired, was already used, or the scope didn't match the action requested — that rejection is logged. Failed attempts are part of the record, not gaps in it.

When decision tokens matter most

Decision tokens apply whenever an AI agent makes a business decision with compliance, consistency, or accountability stakes.

Regulated industries. Financial services, healthcare, and insurance all operate under frameworks that require demonstrable audit trails for automated decisions. The EU AI Act, Article 12, requires automatic event recording for high-risk AI systems, with enforcement beginning August 2026. The requirement is not logs of what agents said — it is records of what agents were authorized to do. Decision tokens give your agents the audit infrastructure they need to satisfy that requirement.

Compliance and legal scrutiny. When a customer disputes a decision or a regulator asks "what did your AI agent do on March 15th," the answer from a system-prompt-based deployment is assembled from conversation fragments. The answer from a Polidex deployment is a structured record with a decision ID. These are not equivalent responses to an inquiry.

Board and executive accountability. The Grant Thornton April 2026 AI Impact Survey found that 78% of business executives cannot pass an independent AI governance audit within 90 days. The governance accountability gap is real and surfacing. When your board or legal team asks "can you demonstrate what your agents were authorized to do?" — decision tokens are the mechanism that makes that question answerable.

Multi-agent workflows. When AI agents hand off to other AI agents, authorization tracking compounds. Which agent authorized what? When? Based on what policy? Decision tokens make the chain traceable even when the workflow crosses multiple systems and agent boundaries. Each handoff is a new decision request; each request produces a new token; each token is an independent record.

Customer-facing consequence. When an agent's decision affects a customer directly — a refund issued, a credit applied, an exception granted or denied — the stakes of inconsistency are immediate. Decision tokens make it possible to answer the question every CS leader eventually faces: "Did we apply this policy consistently across all customers who contacted us about this issue?"

Frequently Asked Questions

What is a decision token in the context of AI agents?

A decision token is a cryptographically signed authorization that a policy engine issues when an AI agent requests permission to take a specific business action. It records what policy applied, what was authorized, which customer and order are involved, and when the authorization expires. It is not a general API credential — it is a one-time, scoped, signed record of a specific policy decision for a specific action. Connectors verify the token before executing any downstream system call, making it the enforcement point as well as the audit record.

How does a decision token create an audit trail for AI agent actions?

Every decision token is logged at issuance and at connector verification. The log entry at issuance records the agent identity, customer context, policy version, authorization scope, and timestamp. The connector log records whether the token was accepted or rejected, and what action was executed. Together, these two records create a traceable, immutable chain connecting a specific business action to the specific policy decision that authorized it. Because the token embeds the policy version active at decision time, the audit record survives subsequent policy changes — a decision made under version 2.3 is still traceable to version 2.3 after version 2.4 is published.

What makes a decision token different from a standard API authorization token?

A standard API authorization token — OAuth, JWT, API key — establishes that an agent is permitted to make requests to a system. It says nothing about which business policy governed a specific action or why that action was authorized at that moment. A decision token is scoped to a specific decision: this customer, this order, this amount, this authorization window. It is single-use, short-lived, and cryptographically bound to every field — changing any field after issuance invalidates the signature. The distinction matters for audit purposes: an OAuth token proves access; a decision token proves authorization for a specific business decision under a specific policy version.

How is a decision token signed and verified?

Polidex signs each token using a private key held exclusively within the Polidex infrastructure. The signature is mathematically bound to every field in the token. Connectors verify the signature using Polidex's public key, which is openly published — anyone can confirm that Polidex signed a token, but only Polidex can produce a valid signature. This is the same asymmetric cryptography model used in TLS certificates and code signing. If any field in the token is modified after issuance — even changing $47.50 to $48.00 — the signature fails verification and the connector rejects the request. The tamper detection is mathematical, not probabilistic.

Can a decision token be used as legal proof of AI authorization?

A decision token is a structured, signed, immutable record of what a policy engine authorized for a specific action at a specific moment. It satisfies the technical requirements for an AI agent audit trail as described in emerging frameworks including the EU AI Act Article 12, ISACA's agentic AI auditing guidance, and the IETF Agent Audit Trail draft specification. Whether a specific decision token constitutes legally sufficient evidence in a particular jurisdiction depends on the legal context — Polidex does not provide legal advice. What the token provides is a precise, verifiable record that an authorization was issued under a specific policy version, with the ability to demonstrate that the connector verified the token before executing any action. That record is defensible in a way that a system prompt is not.

For how decision tokens fit into the broader audit trail architecture, see You Can't Audit a System Prompt. For the governance accountability pressure driving enterprise demand for decision records, see The Governance Accountability Gap.