Security & consent

App Use is safe by construction. Four layers stack on top of one another so that an agent can drive a real application without becoming a way to quietly take it over: capability scopes bound what any token may do, a human-in-the-loop consent gate pauses before write and execute actions, a tamper-evident audit trail records every call, and secret redaction keeps passwords and keys off every surface.

Capability scopes

Every token the SDK issues carries one of three capability scopes:

  • ReadOnly — describe the app and read screen state. Nothing more.
  • ReadWrite — everything read-only can do, plus setting values and invoking actions.
  • Admin — the privileged surface: minting and revoking tokens, mediating consent, reading the audit log, and watching the live tap feed.

Each tool is gated by the minimum scope its risk requires, and the gate is the first thing checked on every call. A read-only agent literally cannot invoke an action — the request is refused before any application code runs. An Admin caller can mint reduced-scope tokens to hand to sub-agents, so a monitoring agent gets read access and nothing else.

ActionMinimum scope
Describe the app, read a screenReadOnly
Set a value, invoke an actionReadWrite
Tokens, consent, audit, live tapAdmin

Human-in-the-loop consent

Scopes decide what an agent is allowed to attempt. Consent decides whether a specific write or execute action actually happens. Before any such action, an in-process consent gate can pause and ask a human for a decision:

  • Allow — let this one call through; the next equivalent call asks again.
  • Allow for the session — remember this decision so the same action on the same element stops prompting.
  • Block — refuse the call immediately.

The decision does not have to be answered on the same machine. The operator Console can take over and mediate the prompt: the app enqueues a pending request, the Console displays it, and the operator decides — and the operator sees exactly which action is pending, on which element, before approving. A hard timeout resolves any stranded prompt to Block, so an operator who walks away or a Console that crashes can never deadlock the app waiting for an answer that will never come.

Tamper-evident audit

Every call is appended to a durable, append-only JSONL log — one line per call, recording the tool, the element, the caller's scope and label, and whether it succeeded. The log is hash-chained: each entry stores an HMAC computed over the previous entry's hash plus its own contents, so the records link together like a chain.

That makes the history tamper-evident. Editing or deleting any past entry — even rewriting the hash itself — breaks the chain at that point, and verification reports the exact entry where it diverges. The Console's audit view shows a green pill when the chain verifies and flags the broken entry when it does not. The HMAC key is minted on first run and stored with restricted permissions; an attacker without the key cannot forge a consistent chain.

Federation keeps its own separate per-hub audit chain for cross-hub calls, using the same hash-chaining technique but an independent key, so a forged record on one side cannot taint the other. See Federation for how that chain is cross-witnessed across a cluster.

Secret redaction

An app marks any sensitive element — a password box, an API-key field — as secret in its AppSpec. From then on its value is redacted everywhere the value would otherwise be exposed:

  • reads and value lookups,
  • screen snapshots,
  • the live tap feed an operator watches, and
  • the audit log on disk.

The redaction happens in the protocol layer before the data leaves the app, so passwords and keys never leak through the surface, never reach a connected agent, and never land in the audit history — regardless of which path the value would have travelled.

Operator identity (Entra ID)

On a hub, operator identity comes from Microsoft Entra ID. Operators sign in once with their organisational account and the hub trusts the resulting token; disabling an operator in Entra revokes their hub access. The hub enforces per-tenant and per-tool access-control lists, so a hub serving more than one tenant stays isolated and each operator only reaches the tools they are entitled to.

When an agent's call crosses into a federated hub, the operator's identity travels with it as a signed delegation envelope — so the receiving hub knows who is really behind a forwarded action and applies its own access rules, rather than blindly trusting the neighbour. Conditional-access requirements such as MFA or device compliance are forwarded transparently and the operator completes the step-up before the call proceeds.