Design AI Permission Surfaces: Inventory and Revocation

A user asks an agent to update a record, and the interface answers with a checkbox that allows the action. They cannot tell whether the agent can read files, reach the network, or store credentials. A bare allow checkbox is a design failure.

Permission surfaces are the product layer where users learn what an agent may touch, what it may not, and how to take it back. Treat them like checkout, onboarding, or error states: a designed experience with states, labels, and feedback.

Inventory the agent before you design the toggle

Inventory every capability the agent can reach before you draw a single control. The list needs one row per agent, tool, plugin, server, or extension, plus the data, files, networks, and secrets it can access.

Start with the machine or deployment environment, then follow the components that depend on each other. Any component that can execute code, hold credentials, browse broadly, or reach the network belongs in the list. Geiger is a read-only command that inventories AI agents, harnesses, MCP servers, plugins, and AI extensions on a machine and reports what each can touch.

Prefer inventory tools that stay read-only. Geiger performs no writes except when the user explicitly names a JSON output file.

Keep the inventory separate from the user-facing surface. Engineers need the full map; users need a digest. Let the list drive labels, boundaries, and audit.

Labels are the permission surface

Label each touchpoint in plain language. The row should state that the agent can read files rather than show a category alone.

Geiger labels each finding with capability categories including EXECUTES, HOLDS-SECRETS, BROAD-FILESYSTEM, BROAD-WEB, and NETWORK.

Use those categories as short labels, but pair every label with the evidence path or example action that proves it. A user should be able to ask how the label was proven and get a concrete answer.

Show both layers when an enforcement layer sits in front of a server. Geiger spots policy wrappers that add an enforcement layer ahead of MCP servers and reports both layers instead of concealing the real server.

Boundaries must be revocable

Turn each label into an action boundary the user can change. The control should state that the agent can read files, with a clear off state and a reason for the restriction.

Scope permissions to the person the agent represents. Workday's Sana agents are limited to the user they represent and to the permissions that user currently has.

Watch for hidden enforcement behind a settings page. If the user cannot see what changed, when it changed, and who can override it, the boundary is decorative.

Make revocation immediate and legible. The finished state means a removed capability, a stopped action, and a visible remaining scope. Surface the new scope in the same view where the user revoked it. If revocation requires a support ticket, add a direct control before launch.

Visible enforcement earns trust

Show enforcement where the user is working. Put a status line, a badge, or a small log entry next to the action, not in a separate admin console. Keep the log entry short enough to read in the flow of work.

Follow the same logic for audit trails as for the permission boundary. In Workday's Sana architecture, Gemini keeps only interaction logs, and the primary audit record stays inside Workday and the customer's environment.

Tie the permission surface to the product that owns the action. Workday launched Sana in March and expanded its Google partnership so that Sana-built agents can be found in Gemini Enterprise.

The audit view should answer three questions: what was allowed, what was blocked, and what changed. When the interface cannot answer them, fix the audit view before asking for trust.

Before shipping, check the surface against the five controls:

• Capability inventory: list every agent, tool, plugin, server, and extension, plus the data, files, networks, and secrets it can access.
• Touchpoint labels: show each capability in plain language, with evidence for the claim.
• Action boundaries: make each label a control the user can change, with a clear off state and reason.
• Revocation controls: remove the capability, stop the action, and show the remaining scope in the same view.
• Visible enforcement and audit: show blocks next to the action, and answer what was allowed, blocked, and changed.