Designing Spend Policies for Autonomous Buyers

“May spend up to this amount” is not a complete delegation.

Evidence boundary: This article is part of Independent Product R&D and documents a Target Reference Architecture. It describes an intended policy model, not measured performance or live operation.

Illustrative Reference Project — not a deployed customer system. The rules and scenarios below are examples for reasoning about governed procurement.

All numbers and names in this example are illustrative.

A useful spend policy combines who is acting, what action is proposed, which supplier and category are involved, how much current and cumulative capacity remains, when the authority is valid, how rapidly it is being used, whether duties are separated, and what evidence is missing. Deterministic evaluation turns that context into allow, require approval, deny, or request clarification.

Policy is a typed decision, not a prompt

An agent can extract candidate facts from a request and explain a result. It should not decide whether “this feels within budget.” The final evaluator consumes normalized facts and explicit state.

Each rule should declare which inputs it needs, how unknown values behave, and which reason it returns. If supplier status is unknown, treating the supplier as approved is not a default; it is an authorization bypass. Unknown decision-relevant input should yield clarification, review, or denial according to policy.

The output needs more than a boolean. A decision record should include the result, matched rules, policy version, evaluated proposal identity, relevant capacity or reservation, required approver role, and safe remediation. That makes the decision reproducible and keeps the agent from inventing a recovery path.

OAuth Rich Authorization Requests provides one useful principle: structured rights can represent fine-grained transaction details. OWASP guidance on excessive agency similarly emphasizes reducing tools, permissions, and autonomy. The target design applies those ideas while remaining protocol-neutral.

Build policy from independent dimensions

Per-action limit

The current proposal must fit its action-specific ceiling. Different categories may use different ceilings because reversibility, supplier terms, and business impact differ.

Cumulative budget

Evaluate completed spend plus reserved in-flight authority, not only settled receipts. Define the time window and which cancellations or failed outcomes release capacity. An uncertain order generally remains reserved until evidence resolves it.

Supplier and category

Supplier eligibility and category eligibility are separate. An approved supplier may not be approved for every category. A known category can still require a specialist approver when data, licensing, safety, or contractual terms are involved.

Validity window

Delegation has a beginning, expiry, and revocation state. Proposal validity may be shorter because inventory or price changes. Evaluate both when authority is consumed.

Velocity

Several individually allowed transactions can signal automation error or split purchasing. Velocity rules examine count, amount, category, supplier, and time without assuming that every burst is malicious. A threshold can trigger review rather than silently expanding authority.

Risk and reversibility

Risk inputs should be explicit and explainable: new supplier, restrictive cancellation, unusual delivery destination, material term change, missing evidence, or low reversibility. Avoid one opaque score as the only reason for denial or approval.

Separation of duties

Policy identifies when requester and approver must be different principals and which role can approve. It also prevents the planning agent or executing workload from satisfying the human approval role.

Spend-policy decision matrix

Conceptual target design. This diagram communicates intended trust boundaries and control flows; it is not a deployment topology or claim of production operation.

The matrix is a review aid, not executable policy. Real evaluation must define precedence and combination semantics. For example, “amount within delegation” cannot override “supplier blocked.” A hard deny should remain deny even if another rule would otherwise allow.

Combine rules with explicit precedence

A clear evaluation order reduces surprising interactions:

1. Validate proposal shape, identity, tenant, and required facts.
2. Reject hard prohibitions such as blocked supplier or forbidden category.
3. Validate delegation status, policy version, and time bounds.
4. Reserve or calculate per-action and cumulative capacity.
5. Evaluate velocity, reversibility, and contextual step-up triggers.
6. Enforce approver role and separation of duties.
7. Return allow, step-up, deny, or clarify with reasons.

This is not the only valid order, but precedence must be deliberate. Do not depend on whichever rule happens to execute last. Tests should cover conflicting rules and prove the intended winner.

Worked example

Consider four fictional requests under one equipment policy.

Request A: USD 480 from an approved supplier in an approved accessories category. The action and cumulative budget are within a valid delegation, no step-up trigger is present, and policy returns allow.

Request B: USD 1,900 from the same supplier and category. It fits the hard ceiling but crosses the illustrative exact-approval threshold. Policy returns require approval and names the budget-owner role.

Request C: USD 320 from a blocked supplier. A low amount does not override supplier status. Policy returns deny with the blocked-supplier reason.

Request D: USD 600 for an item whose category mapping is missing. The evaluator does not guess. Policy returns request clarification, and no execution authority is created.

Now add concurrency. Two distinct USD 1,900 proposals, each with its own request identity, arrive while USD 2,500 remains in the monthly budget. A check performed outside the authorization commit could let both observe the same available capacity and approve USD 3,800 in total. A correct design evaluates reservations atomically, so only one proposal can reserve capacity; the other must be denied, held, or re-evaluated against the remaining USD 600.

These examples are illustrative policy paths, not observed results. They demonstrate how distinct dimensions produce explainable decisions.

Standards references last reviewed: 17 September 2026.

Exact approval should close the proposal

When policy requests step-up, the approval view must show the exact terms that triggered the decision. The proof binds supplier, category, items, quantity, total or ceiling, delivery destination, relevant terms, validity, and proposal identity.

Approval does not disable every other rule. At consumption, policy still verifies hard prohibitions, freshness, cancellation, tenant and role boundaries, and current proposal binding. Whether an approval may override a soft budget trigger is itself an explicit policy decision.

If a proposal changes materially, it returns to evaluation. An agent should not apply a prior approval to a new supplier merely because the price decreased.

Budgets need lifecycle semantics

Define when capacity moves between available, reserved, committed, released, and disputed or uncertain. Without those semantics, teams often count only receipts, which leaves a gap between authorization and settlement.

A denied proposal reserves nothing. An authorized execution reserves capacity. A confirmed outcome converts the reservation according to accounting policy. A proven pre-submission failure can release it. An uncertain result follows the configured hold and escalation rule. Cancellation may release capacity only after provider evidence confirms it.

Policy updates also need version behavior. Existing authorized work should retain the version that allowed it for evidence, while new authorization uses the current version. A critical revocation may block unused grants; that exception should be explicit and testable.

Treat unknown as a designed outcome

Unknown does not always mean deny. Missing category may require requester clarification. Conflicting supplier status may require operator review. Unavailable budget state may fail closed temporarily. The key is that unknown must not become silent allow.

Return structured reasons that the user experience can translate safely. “Category mapping required” is actionable. “Policy failed” is not. Avoid exposing sensitive internal rule detail while still explaining what must change.

Test policy as a decision table

For each rule, test allowed, boundary, exceeded, missing, malformed, stale, and revoked input. Then test interactions: approved supplier with forbidden category, low amount with exhausted cumulative budget, valid delegation with velocity trigger, exact approval from the wrong role, and changed proposal after approval.

Property-oriented tests are valuable for invariants. Increasing an amount should not turn deny into allow without another explicit fact. Replacing an approved supplier with an unknown one should not preserve allow. Replaying a consumed exact approval should not create another authorization.

Failure modes

Implementation checklist

• Define allow, require approval, deny, and request clarification as explicit outcomes.
• Normalize principal, action, supplier, category, constraints, and proposal identity.
• Compose per-action, cumulative, supplier, category, validity, velocity, risk, and role rules.
• Count reserved and uncertain capacity according to documented lifecycle semantics.
• Fail closed on unknown decision-relevant facts.
• Specify hard-deny and step-up precedence.
• Bind approval to the exact proposal and configured approver role.
• Re-evaluate freshness, binding, and hard prohibitions at authorization consumption.
• Return policy version and safe, explainable reasons.
• Test boundaries, concurrency, conflicts, revocation, and material proposal change.

The previous article, Building a Governed Procurement Agent, supplies the surrounding workflow. Continue with From Request to Receipt: A Procurement Transaction Walkthrough to follow one purchase through every control. The project overview and full case study explain the generic target architecture. To discuss private implementation access, request repository access.