Governing Agent Transactions, A series on governing autonomous agents inside the systems that run the business.

In the first post in this series, I described several agents being piloted right now — an invoice agent, a claims agent, a credit agent, a sales agent, an expense agent, a vendor payment agent, a contract agent. Different systems of record, different domains. Same underlying shape: an action with a real, binding consequence, and a condition that defines what the agent is allowed to do and not allowed to do.

Let’s walk through a real example of an AP agent.

A real agent, a real boundary

Below is a trace from an accounts payable agent, built on Amazon Bedrock, connected to QuickBooks Online. It’s the kind of agent teams are standing up right now to handle exactly this workflow: read invoices, track balances, schedule payments, without a human in the approval loop for routine transactions.

Every agent we govern carries one of these: an Agent Card. Think of it as a passport for a runtime agent — its identity, what it’s authorized to touch, and a live record of whether its last commit cleared. Here’s the AP agent’s Card, mid-transaction, the moment a $200 payment ran into a $100 ceiling.

An end user in accounts payable asks it to schedule a $200 payment to a vendor. The agent does exactly what you’d want a competent agent to do — it resolves the customer, finds the invoice, and prepares to create the payment.

But here’s the problem. Accounts payable has a policy restriction that needs to be enforced. Models are probabilistic. You can’t instruct a model into compliance. You can’t control reasoning using permissions written in a prompt. And you don’t actually know, at any given moment, whether the agent in front of you is the one you deployed — or one that’s been compromised or weaponized.

With LangGuard, the AP agent stops.

“I’m unable to process this payment. There is a policy restriction in place that limits payments created via this tool to a maximum of $100.00 per transaction. Your requested payment of $200.00 exceeds that limit.”

The agent itself checked a boundary and declined to cross it — then handed back real alternatives: split the payment, process it manually, escalate to an administrator.

Every step of the accounts payable process was followed. Every limit verified. The accounts payable team would be proud. The question is how you get there — how do you control agent behavior so the accounts payable team can actually trust its actions?

Three gates: Trust, Verify, Authorize

Agents are probabilistic. Once you recognize that, you also recognize you can’t apply enterprise policy to a probabilistic outcome and expect it to hold. Enterprise systems of record are built the opposite way — on deterministic outcomes. Every action that touches one has to clear the same three gates, regardless of what the agent was asked to do or how it reasoned its way there:

• Trust — is this actually the agent it claims to be? Running with the credentials it claims to have, not a spoofed, hijacked, or weaponized instance impersonating it.
• Verify — is this agent even allowed to touch this system, and is this the kind of transaction it’s permitted to make? (Tool, Action.)
• Authorize — does this specific transaction fall inside the boundary defined for it? (Condition — approve or decline.)

Whether you’re building agents that move money, approve claims, apply a refund, or authorize a discount, they all pass through the same three gates. In the AP agent’s case: Trust confirmed the agent’s identity, Verify confirmed it was allowed to call the QuickBooks payments endpoint with a payment-creation action, and Authorize declined the transaction — $200 exceeded a $100 per-transaction ceiling. Two gates passed. One didn’t. The commit stopped.

An instruction tells an agent what it should do. That’s not verification — it’s a suggestion the model may or may not follow, because a model has a thousand paths available and no wall in the way. Trust-Verify-Authorize is different in kind: it’s a checkpoint the transaction has to clear, independent of whether the agent “intended” to follow the rule, the same way a declined card doesn’t care what the cardholder meant to spend.

Every agent that commits needs a Card

Three gates are easy to describe and hard to keep straight across dozens of agents, each touching a different system, each with its own conditions. So we give every agent a Card.

Think of it as a passport for a runtime agent. It carries identity — which agent this is, which runtime it’s operating in, which system of record it’s authorized to touch. And it carries the three-gate record for every commit that agent attempts: Trust confirmed, Verify confirmed, Authorize approved or declined, with the specific condition that decided it.

The AP agent above has a Card. Its Card shows an identity (Agent ID, runtime, authorized system), and it shows exactly what happened when it tried to move $200 through a $100 ceiling — which gate passed, which one didn’t, and why. That’s not a screenshot of a chat log. It’s the record a security review actually wants to see, for every agent, every time.

An invoice agent has a Card. A claims agent has a Card. A contract agent has a Card. Different systems, different conditions, same artifact — because the question every one of them has to answer is the same: who is this, what is it allowed to do, and did this specific commit clear the bar.

What’s next

The AP agent above is one commit, one boundary, one moment. The next post in this series takes the contract agent — where a boundary miss doesn’t just block the commit. It escalates to a human, because a single clause deviating from an approved template is a different kind of problem than a dollar amount running over.

Building a transactional agent? Bring your rules to LangGuard’s AP agent template — we’ll issue it a Card, and make it safe to commit. Just book a meeting at langguard.ai