Skip to main content
The Permissions view is where you connect agents to the secrets they can use. A grant can target a single item or an entire profile (every item in the profile, now and in the future). Each grant is one row at the storage level (agent + target + capability), but the dashboard groups grants by (agent, target) so a single line shows every capability the agent has on that target.

​
Listing permissions

The permissions table groups rows by (agent, target) pair, where the target is an item or a profile. Each row shows:
  • Agent name and kind
  • Target — item label and storage mode, or the profile name for profile-wide grants
  • Capabilities — one chip per granted capability, with read before use
  • Expires — the soonest deadline among the group’s capabilities, or “Mixed” when capabilities have different expiries
  • A small ✕ on each chip to revoke that one capability without touching the others
Filter and search remain row-level (agent / capability / expiry, plus a text search over agent and target), then groups are formed from the filtered rows.

​
Creating a permission

Click Grant permission to open the panel.
1

Select an agent

Only enabled, non-revoked agents are listed.
2

Choose a target

Single item grants access to one credential. Entire profile grants access to every item in the profile, now and in the future. Then pick the item or profile.
3

Pick one or more capabilities

The dashboard shows only capabilities valid for the chosen agent + target, based on the capability matrix (for a profile target, it intersects the matrix across the profile’s current items). Tick as many as you need — multi-grant is atomic. A capability the agent already holds on the target is dimmed and labelled “already granted”.
4

(Optional) Set an expiry

A date. Applies to every capability you ticked in this submission. Leave blank for non-expiring grants. To grant some capabilities with one expiry and others with another, submit two batches.
5

Save

The whole batch lands atomically — every ticked capability becomes one row, all in one transaction. Future access attempts check those rows.
Granting read on an entire profile hands the agent the plaintext of every credential in the profile, now and forever. The dashboard surfaces a confirmation dialog before this specific grant and suggests use instead — the agent runs processes with the secret but never sees it.
The composite unique constraint (agentId, itemId, capability) means each triple has at most one row. The router pre-checks for duplicates so the error envelope can list every conflicting capability up front (meta.duplicateCapabilities).

​
Capability cheatsheet

Invalid combinations (for example, a remote agent + use) are rejected at create time with INVALID_CAPABILITY_LOCALITY or INVALID_CAPABILITY_STORAGE.

​
Revoking a permission

Each capability chip has its own ✕ button. Clicking it deletes that single permission row immediately — sibling capabilities on the same (agent, item) pair are untouched. Any in-flight access attempt that hasn’t yet checked the row sees the deletion and is denied. Audit entries get permission.revoke (one per capability revoked) and permission.revoke_cascade for cascaded denials.

​
Expiring permissions

Set expiresAt to a future ISO timestamp when granting. The server treats a permission as missing once the time passes. Audit entries show result: expired. There is no auto-renewal. To extend a permission, revoke and re-grant with a later expiry.

​
Common patterns