Skip to main content
Restricted vaults and tables are the most protected data in ROOTKey. By default no agent reaches them. An organization can choose to let its members open one of them, for a few minutes, to their own agent.

​
For administrators

The option is off until you turn it on. It is in Organization Settings, on the AI agents tab: the option that lets members open Restricted data to their own agents. The API reports it as allowRestrictedStepUp on GET /organization.

​
For members: how an approval works

1

The agent is refused

It reads or writes a Restricted vault or table and gets agent_step_up_required.
2

The agent asks you

It calls POST /agent-step-ups with the vault or table address, and gets an id, a url and expiresAt. It gives you the url. The request stays open for 10 minutes. If the agent asks again while it waits, it gets the same request.
3

You approve or deny

You open the url in ROOTKey and approve with a fresh two-factor check, or you deny.
4

The agent checks once

It reads the answer with GET /agent-step-ups/{stepUpId}: PENDING, APPROVED, DENIED or EXPIRED. It checks once after you say you approved, never in a loop, and then repeats its call.
In the ROOTKey MCP server, the two tools are rootkey_request_restricted_access, which returns the link to give you, and rootkey_get_restricted_access_status. Both need only the rootkey.read scope.

​
What an approval unlocks

Everything else still applies: the scopes of the token, the organization’s mode, your role and your teams. Listings keep showing Restricted rows with agentAccessible: false, approved or not. If you deny a request whose approval is still running, the approval is withdrawn at once. A file audit report on a file in a Restricted vault also works once you have approved that vault.

​
Errors

With the option off, the request itself is refused with agent_restricted_data_denied.

Delete approvals

Approve every delete an agent asks for.

AI agents in your organization

The settings an administrator chooses for agents.