Put the Agent's Authority in Writing

The signal this week

TechCrunch reported on October 13 that American Express introduced an Intent Intelligence Framework meant to stop AI agents from making unauthorized purchases. As TechCrunch describes it, the flow captures the customer's instructions and constraints, such as merchant, maximum budget and product preferences. The customer verifies identity and approves what was captured. An Intent ID and a Proof of Intent Token are then created, and the token is used to get a digital payment credential the agent uses at checkout in place of the customer's card number.

It's a proposed framework, not a live product, and the article gives no availability date. Amex told TechCrunch it hasn't yet seen an increase in disputes from agentic commerce and wanted to build ahead of the volume. TechCrunch reports no measured reduction in wrong purchases.

Separately, Workday announced its Trusted Agent Platform and says every action running through it stays bound to Workday's permissions, approvals and audit trails. That's a vendor claim about its own platform.

Neither announcement tells a small business whether its own workflow has a working boundary.

What the sources show and don't

NIST's AI Risk Management Framework supports human oversight, mechanisms to disengage a system that behaves outside its intended use and monitoring in production as management practices. It's voluntary. It doesn't prescribe this card or prove that a particular control works.

The strongest objection is duplication. A company that already has purchase approval or change control should extend that record instead of adding a parallel system.

Authority is five boundaries

An agent's authority is the intersection of its credential, the data it can reach, the actions it's permitted and the approval rule in front of them. Put those boundaries on one card with a business owner and a technical stop owner.

The card is a Governance Posture tool. It also cuts the Verification Tax, because the reviewer inspects the same record that governed the action.

Run one allow and one deny

Pick a workflow that matters and can be tested without real money or customer messages. Use synthetic or redacted data. The business owner writes the permitted vendors, the amount ceiling, the data scope and the external-send rules. The technical owner maps those rules to the credential and the tools. A separate reviewer watches one allowed action and one blocked action.

Passing means the allowed action follows the approved path, the forbidden action is blocked before it completes and the log shows the approver, time, credential and reason. A failed test becomes a hold on wider action with a named fix owner. Record the actual time and effort if you'll later claim value. This briefing has no value baseline.

Five prompts to run this week

Use approved exports or synthetic records only. These prompts prepare a decision record. A person verifies every result against the source rows and watches any test.

Using only the approved workflow description and agent inventory export I provide, identify the one workflow under review. Return the business purpose, named business owner, technical owner, agent identity, credential ID, connected systems and source row IDs. Mark every absent field UNKNOWN. Separate quoted source facts from your inferences. Do not infer access from a product name or execute any action.

What this should tell you: whether the identity and owner record is complete enough to assign authority. Watch for an UNKNOWN owner, a personal credential, a missing system or an uncited inference. Decision: select this workflow only when a business owner and a technical owner accept the inventory. Otherwise send it back.

Using only the verified Prompt 1 row and approved system permission exports I provide, list the data classes, vendors, records and tools this credential can reach. Separate read, draft, send, spend and change permissions. Record any amount ceiling and external destination rule. Cite source row IDs and mark missing evidence UNKNOWN. Do not assume a permission is blocked because it is absent from a narrative description. Do not execute any action.

What this should tell you: what the credential can actually reach. A narrow business request can still sit on a broad credential. Watch for broad scopes, unlisted destinations, missing ceilings and any permission with no source row. Decision: change the credential before testing if the scope is unknown or excessive.

Using the verified workflow and permission map, draft one Agent Action Authority Card with business owner, credential, allowed data, permitted actions, vendor and amount limits, human approval triggers, stop owner, rollback path and review date. Distinguish the current permission from the proposed limit. Mark unresolved fields UNKNOWN and cite each supporting source row. Do not invent an approval or claim the card is signed.

What this should tell you: the proposed limits in one place. Watch for a proposed rule presented as an enforced setting and for a missing stop owner. Decision: the business owner accepts or narrows the scope, and the technical owner maps each accepted limit to a real control. Writing a limit doesn't enforce it.

Given the owner-reviewed authority card, the technical control mapping and a synthetic workflow, draft one allowed case and one denied case. For each, state input, expected behavior, exact log evidence, observer, safe environment, rollback step and stop condition. Mark any control that cannot be observed UNKNOWN. Do not run commands, send messages, alter records or initiate purchases. Do not report a test result.

What this should tell you: whether the plan can show a block before completion. A plan can expose a gap but it can't prove the boundary works. Watch for a missing observer, rollback or evidence capture. Decision: approve a safe test only when both cases and the stop path are observable.

Using only the signed authority card, approved control mapping and observed allow and deny logs I provide, prepare a decision brief. Show the exact evidence for each expected behavior, any missing log, deviations, review date and unresolved risk. Separate observed facts from inference. If a log or approval is absent, mark the case UNVERIFIED. Recommend hold or limited expansion with explicit conditions. Do not certify a pass or invent a measured benefit.

What this should tell you: whether the evidence supports a decision for this one workflow. Watch for a completed forbidden action, a missing denial event or an approval added after the action. Decision: approve limited action only when the card is signed, the allowed case followed the approved path and the denied case was blocked. Otherwise hold and name a fix owner.

What to do this week

The CEO or operating owner selects the workflow and names a business owner. The CIO or technical lead assigns the credential and stop owners. Approve wider agent action only after the card is complete and the allow and deny test has been observed.

A fair limit on all this

The Amex framework is a proposal, and TechCrunch reports no measured drop in wrong purchases. Workday's article describes its own platform and is a vendor claim. Neither verifies what a small business's controls actually do. The card, the allow and deny test and the measures below are SML operating practice.

A passing test shows that one boundary worked under the recorded conditions. It says nothing about a new tool, a broader credential or value. Keep the original test conditions so a later owner can repeat the test. Recheck when a tool, data source, vendor or action changes. Track the share of active agents with a complete card and the share with a current test. They're proposed measures, and no improvement is claimed.