The past two years have pushed AI from a curiosity into the operational core of financial institutions. Anthropic's finance agent work has demonstrated how large language models (LLMs) can handle complex, multi-step financial tasks — reconciliations, document review, compliance checks — that previously required dedicated staff. Microsoft and OpenAI have brought AI directly into Excel and the Office productivity layer that finance teams live in, automating analysis that used to take hours. Across the enterprise, procurement, accounts payable, treasury, and audit functions are beginning to delegate real work to AI systems.

The distinction that matters here is between AI that advises and AI that acts. A model that summarizes a vendor contract is low-risk. A model that approves it, creates a purchase order (PO), and initiates a payment is a different situation entirely. The shift from assistant to agent — from answering questions to taking actions with business consequences — changes the security posture of every system it touches.

This is where most implementations have a gap. The AI is capable. The workflows are real. The authorization layer is borrowed from a world where humans were the actors, and it is not keeping up.

The procurement use case

To make this concrete, consider a procurement scenario at a mid-size company. We will call it Meridian Corp.

Meridian has a mix of roles involved in purchasing: procurement managers who own departmental budgets, a VP of Finance with cross-company oversight, and AP (accounts payable) clerks who handle payment execution. The company has deployed an AI agent to handle purchase order creation, approval workflows, and vendor payment processing. The agent has direct access to internal systems and acts on behalf of whoever is logged in.

The authorization requirements are not flat:

• A procurement manager can approve POs in their own department, up to their personal approval limit, but not POs they created themselves.
• The VP of Finance can approve anything, across any department and any amount.
• An AP clerk can process payments, but only to vendors that hold a LOW risk tier. Procurement managers cannot process payments at all.
• Nobody can approve their own POs, regardless of role.

These are not edge cases. They are the normal operating rules of a real procurement function, and they directly reflect regulatory requirements around segregation of duties (SoD) and spend controls that auditors will look for.

Why traditional access control falls short

Traditional access control, role-based access control (RBAC) for example, was designed for a world where access decisions are relatively static. A user has a role. The role has permissions.

The permissions are checked at login or at the gate of an endpoint.

This model runs into problems well before AI agents enter the picture. In the Meridian scenario — with only human users — the authorization logic already cannot be expressed cleanly in roles. "Alice can approve Engineering POs under $25,000, except ones she created" is a contextual decision that depends on the combination of who Alice is, what the PO contains, and who created it. To express that in pure RBAC, you start multiplying roles: approver_engineering, approver_engineering_under_25k, approver_not_own_pos until the role table is unmaintainable and the real policy logic has leaked into application code or database queries.

Introducing an AI agent makes this worse in specific ways:

• The agent acts on behalf of users across contexts. An agent may act on behalf of Alice for one tool call, then on behalf of David for the next, within the same session. Its effective permissions need to shift with context, not be pinned to the agent's own identity.
• The agent executes multi-step workflows in a single request. A human user triggers one action at a time. An agent asked to "approve all pending purchase orders" fans out into many parallel actions. Each one needs to be authorized independently, with the correct context for that specific action and resource.
• The agent's behaviour can be influenced. A human user has intent. An agent processes inputs, including document content, tool responses, and data from external systems, that can be crafted to manipulate what the agent does next. This is not a theoretical risk: prompt injection through malicious document content or tampered tool responses is a documented attack vector for LLM agents. An authorization layer that relies on the agent behaving honestly is not a reliable control.

Dynamic access control to the rescue

Dynamic access control including, attribute-based access control (ABAC), policy-based access control (PBAC) and runtime access control, evaluates access decisions as logical expressions over attributes — attributes of the subject (the user), the action being taken, and the resource being acted upon. There are no pre-computed permission tables. A policy engine evaluates each request against a set of rules at runtime.

For the Meridian scenario, the full authorization model fits in three policies:

Policy	Condition	Effect
Approve / Reject PO	User created the PO	🔴 DENY
Approve / Reject PO	Role is vp_finance	🟢 PERMIT
Approve / Reject PO	Role is procurement_manager AND PO is in user's department AND amount ≤ spend limit	🟢 PERMIT
Approve / Reject PO	Any other case	🔴 DENY
Process Payment	Role is vp_finance	🟢 PERMIT
Process Payment	Role is ap_clerk AND vendor risk tier is LOW	🟢 PERMIT
Process Payment	Any other case	🔴 DENY
View / Create / List	Any authenticated user	🟢 PERMIT

Three policies replace what would otherwise be a tangle of application-level checks, role proliferation, or — worse — logic embedded in the agent's system prompt.

How the policy looks in ALFA

Abbreviated Language for Authorization (ALFA) is the human-readable standardized policy language used by Axiomatics. The three policies above translate directly:

Policy 1 — Approve / Reject Purchase Orders

policy ApprovalPolicy {
    target clause action.actionId == "approve" or action.actionId == "reject"
    apply denyUnlessPermit
    rule permitVpFinance {
        target clause subject.role == "vp_finance"
        condition not(subject.userId == resource.createdBy)
        permit
    }
    rule permitProcurementManager {
        target clause subject.role == "procurement_manager"
        condition resource.costCenter == subject.department && resource.amount <= subject.spendLimit && not(subject.userId == resource.createdBy)
        permit
    }
}

Policy 2 — Process Payments

policy PaymentPolicy {
    target clause action.actionId == "process_payment"
    apply denyUnlessPermit
    rule permitVpFinance {
        target clause subject.role == "vp_finance"
        permit
    }
    rule permitApClerkLowRisk {
        target clause subject.role == "ap_clerk"
        condition resource.riskTier == "LOW"
        permit
    }
}

Policy 3 — View / Create / List

policy ViewCreateListPolicy {
    target clause action.actionId == "view" or action.actionId == "create" or action.actionId == "list"
    apply denyUnlessPermit
    rule permitAllAuthenticated {
        permit
    }
}

How enforcement is wired into the agent

Every tool the agent can use calls the Axiomatics Authorization Management Platform before executing. The pattern is the same across all actions — build a request from the user's attributes and the resource context, call the engine, gate the action on the response:

# Before any agent action — pseudocode
decision = axiomatics.authorize(
    subject={"role": user.role, "department": user.department, "spend_limit": user.spend_limit},
    action="approve_po",
    resource={"cost_center": po.department, "amount": po.amount, "created_by": po.created_by}
)

The agent tool never encodes policy logic itself. It asks the Axiomatics Authorization Management Platform and acts on the answer. Because all decisions flow through a single engine, the decision log is naturally centralized — a single audit trail that covers every action taken by every agent or application that calls it, not a collection of per-application logs that need to be reconciled after the fact.

Note — where attributes come from

The authorization request above passes user and resource attributes that the application has already fetched. The Axiomatics Authorization Management Platform can also retrieve attributes directly from external sources — SQL databases, LDAP directories, and other systems — through built-in attribute connectors. This means the policy can reference data the calling application never had to retrieve itself: current employment status from an HR system, real-time credit limits from a treasury database, vendor classifications from a risk registry. The application supplies what it knows; the engine fills the rest from authoritative sources.

Adding AP2: defense-in-depth for agentic payments

The dynamic access control layer on the agent handles most of the policy surface. For payment actions specifically, a good security architecture enforces policy at the payment processor as well — as a separate, independent service component — rather than relying solely on the agentic application having done it correctly upstream.

One example where this is already specified is the AP2 protocol (Agent Payments Protocol) from Google. AP2 defines a cryptographically signed delegation chain for AI-initiated payments. The user issues an OpenPaymentMandate that delegates payment authority to the agent for a specific payee and amount. The agent closes it with a PaymentMandate. The resulting chain is a dSD-JWT (delegated Selective Disclosure JSON Web Token): each hop is signed by the respective key and the binding between hops is cryptographically enforced.

In the Meridian demo, payment processing runs two independent ABAC checks:

User → [Axiomatics Authorization Management Platform: Layer 1, inside agent]
     → AP2 mandate chain created (signed by user key, then agent key)
     → AP2 Processor → [Axiomatics Authorization Management Platform: Layer 2, inside processor]
     → Payment executed

Layer 1 runs inside the agent tool, before the mandate is constructed. A Deny here means no mandate is created and no payment request leaves the agent. This is an early gate — catching a policy violation before a mandate is built is more efficient than submitting one that the processor will reject.

Layer 2 runs inside the payment processor service, independently. The processor does not assume that the upstream agent check was performed, or performed correctly. It evaluates the same policy on its own authority: it receives the mandate chain, verifies the cryptographic signatures, and then calls the Axiomatics Authorization Management Platform directly using the attributes embedded in the mandate. A valid chain establishes who authorized the payment and for what. Whether policy permits that payment is a separate question, answered independently at the processor.

The two layers use the same Axiomatics Authorization Management Platform and the same policies. The processor's enforcement is not contingent on the agent's — each component owns its own policy decision.

Architecture showing the Meridian Corp agent, MCP tools, the AP2 processor, and the Axiomatics Authorization Management Platform as the shared policy authority across both layers.

What this looks like in practice

The demo runs three scenarios that together cover the full policy surface:

1. The SoD trap. Alice, a procurement manager, asks the agent to create a $5,000 PO and then approve it in a single prompt. The agent creates it successfully, then is immediately denied when it tries to approve its own creation.
2. Spend limit and cost centre. Alice asks the agent to approve all pending orders across the company. Marketing POs are denied (wrong department). An Engineering PO over $25,000 is denied (over her approval limit). The rest are approved.
3. Vendor risk tier and AP2. David, an AP clerk, asks the agent to process payments for all approved POs. For each payment, the agent builds a cryptographically signed AP2 mandate chain before submitting to the processor. The LOW-risk vendor payments clears both the agent-side and processor-side ABAC checks. The HIGH-risk vendor is denied at both layers.

In every case, the policy enforcement is handled by the Axiomatics Authorization Management Platform — not in the agent's system prompt, not in application-level conditional logic, not in the LLM's judgement. Every decision is logged centrally, producing a ready-made audit trail that spans both the agent and the payment processor without any additional instrumentation.

The case for a dedicated authorization layer

There is an alternative to a dedicated policy engine: implement the checks in application code. A few conditionals, some role lookups, a permission table. This works at small scale and low complexity.

It stops working cleanly when the number of attributes grows, when policies need to change without a code deployment, or when the same policy needs to be enforced independently across multiple services — as is the case when both the agent and the payment processor must evaluate decisions autonomously. And it stops working entirely when a compliance audit asks for a complete, tamper-evident record of who was permitted or denied access to what, when, and why — across every application in the estate, not just one.

Axiomatics builds authorization infrastructure for exactly this problem. The Axiomatics Authorization Management Platform is a high-performance policy decision point built on that:

• Evaluates fine-grained, attribute-rich policies in real time
• Decouples policy logic from application code — policies live in ALFA, not scattered across agent tools and service handlers
• Produces a centralized, tamper-evident decision log across every application that calls it — a single audit trail that satisfies compliance and governance requirements without per-application instrumentation
• Enforces the same policy consistently whether the caller is an AI agent, a payment processor, an API gateway, or a human-facing application

The demo in this post uses the Axiomatics Authorization Management Platform as the single policy authority for both the agent and the AP2 processor. Adding a new rule — a new risk tier, a new approval hierarchy, a new segregation requirement — means updating the ALFA policy in one place.

For teams building AI agents in regulated financial environments, where policies need to be auditable, consistently enforced, and maintainable without touching application code, a central dedicated authorization engine is the right foundation.

If you are working on AI agent deployments in finance and want to explore what dynamic authorization looks like for your use case, get in touch with Axiomatics.