Agent Access and AI Governance

This concept covers the control room for machine callers. If an outside AI client is going to read a catalog, place an order or update a status on someone's behalf, three questions need permanent answers: which operations is it allowed to call, which of those move money or change customer-visible state, and where is the record of what it actually did. The two illustrated surfaces answer those separately — one for the person connecting a client, one for the administrator setting policy for the whole environment.

The design's central assumption is that an agent should never hold more reach than the human it acts for. The connected-client card states the scope plainly as the signed-in person's own permissions, and the tool table then narrows that further, marking each operation as a read or a write and attaching a confirmation rule to the writes. Some operations are shown as requiring confirmation before they run; one family is shown as denied outright at the server, not merely hidden in the interface, which is the distinction that matters when the caller is a program.

The first illustration shows the agent access area: a connected desktop client with its scope and a disconnect control, a table of available tools grouped into families with access and confirmation columns, and a side rail listing recent tool calls with timestamps, outcomes and the actor behind each one. A status card beside it lists hardening items such as a schema correction pass, confirmation for money-moving tools and recording where each request originated. The second illustration moves to an admin AI policy surface: summary tiles for protected and self-scoped fields, audit coverage and spend metering, a controls table stating where each control is enforced and whether it is active, feature flags including one held closed pending an approval, a published terms panel and a feed of recent audited writes with masked arguments.

In the wider product, this is the layer that makes the in-context assistant and its daily proposals safe to extend outward. The same permission model that governs a person in the console governs an agent calling on their behalf, enforcement is shown happening at the gateway, in the schema and in the service rather than in one place, and every write leaves a redacted trail. The design deliberately lists every control with its own status, whether active, closed or not yet started, so the surface reads as an inventory of coverage rather than a reassurance.