A2UI / agentic UI: the AI that acts inside your apps

Let's start with an honesty note, because this topic is a naming mess and pretending otherwise would fail you at an exam.

If you go looking for "A2UI," you'll find a real thing — Agent-to-UI, a Google-originated protocol for agents to generate user interfaces on the fly (candidate spec, v1.0 still a release candidate as of mid-2026, with production still pointed at v0.9.1) (a2ui.org). But A2UI is about an agent drawing a screen. It is not the thing that should worry a compliance owner. The thing that should worry you sits one layer over: agentic UI / computer-use — AI that operates your existing applications, clicking buttons, filling fields, and submitting forms on a person's behalf. That's the real governance story, and "A2UI" has become loose shorthand for it. This post covers the real landscape under that banner, and calls the parts by their right names.

What happened

Over the past two years, "computer use" went from demo to product. Anthropic shipped a Computer Use capability for Claude (first released October 2024; heavily expanded through 2026, with Anthropic publicly positioning Claude to "use your computer to finish tasks for you") (CNBC, Mar 2026). OpenAI's Operator folded into ChatGPT "agent mode." Google's Project Mariner and Amazon's Nova Act round out the API-first field (Digital Applied comparison, 2026). Alongside them, a wave of agentic browsers — tools that drive the web through a real browser session — moved into everyday use (agentic browser landscape, 2026).

What they share: the agent doesn't call a clean API. It uses the app the way a person does — through the same screen, the same login, the same buttons. To the application on the other side, it often looks exactly like a human employee working.

Separately, protocol scaffolding is forming around this: AG-UI (a runtime event stream between an agent and an interface) and the A2UI rendering spec named above are being described as part of a six-protocol "agent stack" for 2026 (protocol-stack overview). Useful context — but the exam-relevant fact is simpler: software now takes actions inside your systems wearing a human's badge.

Why it matters

Your audit trail answers one question above all others: who did this? Every control you have — segregation of duties, maker-checker on a wire, "the CCO reviewed and approved," access reviews — rests on the log naming a person accountable for an action. Computer-use agents attack that foundation directly. When an agent acts through a human's session, the log records the human. The action was the machine's. The accountability record is now, quietly, wrong.

This is the same "who did this?" fracture the agent-identity post takes on from the credential side — here it shows up at the point of action, inside your applications, where your evidence is actually generated.

Concretely, three things break:

• Attribution. "User jsmith submitted the change" may mean jsmith's AI assistant did, unsupervised, at 2 a.m. The name in the log is no longer a reliable claim about who decided.
• Segregation of duties. If one employee's agent can both initiate and approve — because it's driving two screens under two saved logins — the control exists on paper and not in fact.
• Reconstruction. When something goes wrong and you need to reconstruct what happened, "a person clicked this" and "an agent clicked this" are very different findings. If your logs can't tell them apart, you can't reconstruct, and reconstruction is half of what an incident response program is for.

What it means for you

If you're a credit union or community bank — Your exposure is concentrated where staff touch member data and money movement inside core, digital-banking, and back-office systems. The question isn't hypothetical adoption someday; it's whether staff are already using an AI assistant or agentic browser to move faster through those screens. Do-this-Monday: (1) ask, in your next AI use inventory, whether any tool "acts on your behalf" in member-facing or transaction systems — that phrase catches computer-use even when staff don't know the jargon; (2) confirm your logging on money-movement and data-modification actions captures session origin, not just the username. NCUA diligence is proportional (07-CU-13), so weight this toward core and high-risk systems — but the "who did this?" question there is not optional.

If you're an RIA or broker-dealer — Reg S-P requires a written incident-response program and, for provider breaches, notice to your firm within 72 hours and to affected customers within 30 days — and Reg S-P is a named SEC Examinations FY2026 priority. An incident-response program that can't distinguish a human action from an agent action inside your own systems has a hole in it. Do-this-Monday: put one question to yourself and your key vendors — when an action is taken in this system, can we tell whether a person or an automated agent took it? If a vendor's answer is "the log shows the logged-in user" with no way to flag agent-driven actions, that's a finding to document now, not to discover during an incident.

How to get ahead of it

1. Name it in policy in plain language. You don't need a computer-use policy that reads like a research paper. You need one line: tools that act inside our systems on a user's behalf must be inventoried and approved, and their actions must be attributable. Plain enough that staff know what it covers.
2. Make "session origin" a logging requirement. When you assess an application — yours or a vendor's — ask whether the audit log can distinguish human from agent action. Write down the answer. A "no" is a documented risk you've accepted knowingly, which is a defensible posture; a "no" you never noticed is not.
3. Protect the money-movement and approval paths first. Proportionality again: the wire screen and the trade-approval workflow earn scrutiny the internal wiki doesn't.
4. Keep the "no" evidence. "As of [date], no approved tool acts on a user's behalf in [system]" is a clean, dated line for the binder — and a baseline you can prove you moved from later.

What to watch out for

The overreaction: a blanket ban on AI assistants. It won't hold — staff will use them anyway, now off the record, which is strictly worse than governed use. The goal is attribution, not prohibition.

The snake oil: vendors selling "AI action monitoring" that inspects traffic without ever answering the accountability question. Watching packets fly by is not the same as your log naming who is responsible for an action. Ask any such tool a single question: after the fact, can you tell me whether a human or an agent did this specific thing? If it can't, it's telemetry, not oversight.

The false comfort: "our vendor has SOC 2, so their logging is fine." SOC 2 audits were largely built around human user access; agent-driven actions inside an application can sail straight past that scope. A certification is not a substitute for asking the attribution question yourself.

The bottom line

The AI acting inside your apps doesn't announce itself — it wears your employee's login and shows up in your logs as a person. The exposure isn't exotic; it's the oldest control question you have — who did this? — with a new way to get the wrong answer. Getting ahead of it is mostly inventory and one logging requirement, both of which a Discover scan is designed to surface: which tools act on your behalf, and whether the record can still tell a human from a machine.

See what a Discover scan finds — including the tools already acting inside your systems that never made it onto a list.