What Can Your Agent Controls Prove After an Incident?

A customer-service agent can issue refunds up to an approved limit of S$1,000 per transaction. It issues a refund of S$4,800 through a refund API it is permitted to call. The request is well formed, and the money leaves.

Access to the refund API was never in doubt. What the incident review, and later internal audit or a regulator, will want to establish is whether the agent had authority for this refund, and if not, where the chain broke:

1. Who authorised it?
2. Which control was meant to enforce that authority, and what did it do?
3. Can the records show which of these happened?

For the people who design these systems, that becomes an architecture problem. The evidence sits in at least two places, the agent layer and the system that moved the money, and it answers the questions only if the two can be linked. This article works through six ways the refund could have happened and the seven records needed to tell them apart. The same records serve testing and ongoing oversight long before an incident. The scenario is hypothetical; the shape applies to any agent that can move money, change records or commit the business.

Start with the system of record

An architect’s first question will be why the refund platform itself did not stop it. Payment and refund systems typically enforce their own per-user limits and maker-checker approvals. If the agent’s identity in that system had carried the S$1,000 limit, the refund would have failed there. If the agent connects through an integration account created for another purpose, that account’s limits reflect the other purpose, not the agent’s delegation.

The system of record is often the strongest place to enforce a monetary limit, because it sits on the only path to the money. An agent-layer control adds context the system of record lacks: which agent asked, for which task, after which prior steps. The rest of this article assumes both layers exist and asks what evidence connects them.

The argument

A runtime control evaluates an agent’s proposed action and allows it, blocks it or sends it for approval before it executes. It can show that an action matched an encoded rule. Whether that rule represented valid business authority is a separate question, and it needs separate evidence. Buying a stronger control improves one link in the chain. It does not create the others.

Six illustrative causes could explain the refund. The list is not exhaustive, and several can occur together.

Authority failures, where the controls may have worked as configured:

• Wrong rule. The configured limit was S$5,000, although the approved delegation was S$1,000.
• Wrong identity. The agent acted through credentials whose limit in the refund system exceeded its delegation.
• Unauthorised approval. The control escalated the refund, but the approver lacked the authority, or was also the requester.

Enforcement failures, where the controls did not work as intended:

• Bypass. The refund reached the refund system by a route that did not pass through the control.
• Monitor-only mode. The control recorded a deny but was configured to log rather than block.
• Mismatch. The control approved one request, and a different request executed.

These are hypothetical failure paths, not claims about any product named below.

1. Who authorised it?

The authority failures happen before or outside the runtime check. A control can enforce a S$5,000 rule exactly as designed while the organisation exceeds its approved S$1,000 delegation.

The published specifications for agent runtime control separate policy evaluation from enforcement. In Microsoft’s Agent Control Specification, part of its open-source Agent Governance Toolkit, a runtime computes the result and the host system must enforce it. The OWASP Agent Control Standard defines where a control can attach to an agent. I have not found guidance in either on how a business delegation becomes a rule; that translation sits with the organisation.

Ruling out the authority failures means following a chain. It starts with the person who approved the S$1,000 delegation, and exactly what they approved: per transaction or per day, in which currency, for how long. It runs through the policy version live at the time of the refund, and whether that version matched the delegation, and through the credentials the agent used in the refund system and the limits they carried. For an escalated action, it ends with the approver: whether they held the authority, and whether they were independent of the request. A break anywhere in that chain can produce the refund while every individual control behaves as configured.

2. What actually enforced it?

The enforcement failures depend on where the control sits: where it intercepts the action, how much of the transaction it can see, and how well it is protected from the agent. Four published designs illustrate the main placements. They are not a shortlist, and they differ widely in maturity.

Inside the agent’s process. Kyvvu, a Netherlands-based start-up whose SDK is open source, runs an enforcement engine inside the agent’s harness (the code that runs the agent’s loop and calls its tools). It evaluates each action against the prior steps, so it sees the refund amount and its history as the harness declares them. An action that does not go through the harness is invisible to it. For the investigation: its log shows what it evaluated, but not whether every refund passed through it.

An external permission service. Meta’s consumer agent Muse routes actions through a separate service, Sentinel, which runs outside the agent’s container and alone can grant execution permission. It inspects requests down to the decoded payload. Meta does not sell Sentinel; it is a published pattern an enterprise can reproduce with its own gateway. For the investigation: a control can be separate from the agent and still see the transaction, which narrows the room for bypass and mismatch, provided the refund API is reachable only through it.

An isolated sandbox with a network gateway. Perplexity’s open-source SPACE runs each agent session in its own lightweight virtual machine and forces all outbound traffic through a gateway that enforces network policy and injects credentials the agent never sees. That keeps the agent’s identity in the refund system outside its reach. In Perplexity’s own red-team testing, agents bypassed the network policy in 11 of 54 runs that allowed some network access; after fixes, its re-evaluation found no verified bypass. That is vendor-run testing, but it shows why a gateway needs testing for routes around it. For the investigation: the gateway shows which destinations and credentials the agent used, but an over-limit refund to a permitted endpoint looks like any other permitted call.

A monitor on separate hardware. NVIDIA’s Sentry, a reference design announced in September 2026 with no general availability date, observes agents from network cards with their own processors, outside the agent’s host. NVIDIA says it can link agent actions, policy decisions and tool access into one activity record. For the investigation: an independent vantage point could help detect a bypass. This is a vendor claim I have not validated.

Three points apply whatever the placement.

Bypass is a coverage question. Which routes from the agent to the refund system avoid the control? Candidates include direct network calls, sub-processes, secondary tools and helper agents with broader access. My earlier article, Who Checks the Harness?, covers why a control’s builder is poorly placed to find them.

Mode is a configuration question. Microsoft’s specification has an evaluate_only mode in which the host may carry out the original action, producing a deny record for a refund that still went through. Record the mode with every decision. Record failure behaviour too: failing closed stops unchecked refunds, and also legitimate ones while the control is down.

Mismatch is a linkage question. A checked request can differ from the executed one through a retry, a downstream transformation or a second call. Microsoft’s specification recommends recording digests (cryptographic fingerprints) of the input evaluated and the input passed on for enforcement. Those show what the control approved, not what the refund system received. That needs a receipt from the refund system, matched to the approved request.

3. What can the records establish?

The records need integrity (unaltered since written), completeness (every relevant action captured, including any that bypassed the control) and linkage (each decision connected to the outcome in the system of record). Completeness cannot come from the control’s own log, because a bypassed refund will not appear there. It comes from reconciling decision records against the refund system’s own records.

The attribution gap

Reconciliation has a weakness that is easy to miss. It can reveal a refund with no matching decision and still fail to identify which agent initiated it.

If several agents, batch jobs or integrations share one service account in the refund system, the refund record shows only that account. The investigator knows something happened outside the control, but not what did it, on whose behalf, or as part of which task. The unexplained transaction is visible. Its origin is not.

Attribution has to be designed in. Either each agent has its own identity that the system of record captures, or the agent layer passes a correlation identifier that the system of record keeps with the transaction. Without one of these, a bypass can be detected but not investigated, and the review stops where it matters most.

Reading the patterns

Reconciliation produces patterns. None proves a cause on its own, and several causes can produce the same pattern. The table is a guide to possible explanations and the next check, not a diagnosis.

Specifications leave much of this record-keeping optional. In Microsoft’s specification, a decision may carry a pointer to a verifiable proof, and audit records should include the intervention point, result and reason. If you need those records, your contracts and configuration have to require them.

What to put in place

For Singapore financial institutions, this is becoming a supervisory question. MAS issued its final Guidelines on Artificial Intelligence Risk Management on 7 October 2026: sections 3 and 4 apply from 7 October 2027, and sections 5 and 6 by 7 October 2028. Institutions remain accountable for AI used in their services even when a third party develops or operates it, and MAS intends to consult on agentic AI guidance in 2027. The guidelines set expectations. Meeting them for one specific agent action is left to the institution.

From your organisation:

1. Delegation record. Who approved each agent’s authority, its scope and its validity period.
2. Policy version history. Each rule that encodes a delegation, linked to that delegation.
3. Identity mapping and attribution. The credentials each agent uses in each target system, their limits, and how the system of record identifies which agent initiated each transaction.
4. Approval records. Who approved each escalated action, and their authority to do so.

From the control, whoever supplies it:

5. Decision records. The result, the mode, the control that issued it and where it runs.
6. Execution linkage. A way to match each decision to the receipt from the system of record.
7. Evidence integrity and completeness. How records are protected from alteration, and reconciled against downstream systems to detect missing activity.

These records support an investigation; they do not guarantee a conclusion. They help only if they are accurate, detailed enough and reliably linked. Where one is missing, other evidence can sometimes fill the gap, usually at much higher cost. If your agents are not yet in production, these records are far cheaper to design in now than to reconstruct after an incident.

What the Lab will test

Aivance’s Runtime Control Lab is preparing to run this refund scenario in a baseline environment and three control configurations. The planned tests include three authority tests (threshold breach, invalid approver, separation-of-duties failure), two adversarial cases (prompt injection and misuse through a permitted endpoint) and a check of evidence retention. Results will be published once validated. Until then, this article reflects published documentation and vendor claims, not test results.

Disclosure: Aivance is in partnership discussions with Kyvvu. No commercial agreement is in place, and Kyvvu had no input into this article.

Sources

• MAS, media release on the final AI risk management guidelines and Guidelines on Artificial Intelligence Risk Management, October 2026
• Microsoft, Agent Control Specification, Agent Governance Toolkit
• OWASP GenAI Security Project, Agent Control Standard
• Meta, Security and safety for AI agents: our approach with Muse
• Perplexity, Making SPACE: secure runtimes for long-running agents, July 2026; Escaping SPACE: Part I, September 2026
• Kyvvu, About
• NVIDIA, Open Agent Safety Platform announcement and technical description, 28 September 2026
• Aivance, Who Checks the Harness?, September 2026