Agent access · Proposed experiment
Give access. Keep the underlying key.
Explore a way to let a named agent use one service through a limited, revocable grant, without copying your API key into its configuration.
For people managing credentials across agents who need clearer attribution and independent revocation.
Explore the proposed workflowOne task.
A defined permission
This is a pilot proposal, not a connected service. There is no account setup, purchase, or credential collection on this page.
Define the grant
Name the agent, service, allowed operations, expiry, and any enforceable usage limits.
Use one existing workflow
The proposed proxy authorizes a task without putting the underlying credential into the agent’s context. A metadata-only record identifies the grant used.
Revoke independently
Remove one agent’s access while another grant continues to work. This is a behavior the pilot must demonstrate, not an available control here.
What the boundary
must mean
Permissions must be enforced by the executor or provider. A hidden credential does not prevent misuse of authorized operations, and revoking a grant cannot retract a key previously copied elsewhere. No credential storage, proxy, or agent integration is connected on this page.
This Hito-oriented experiment has its own participants and validation criteria. Interest in the health pilot does not establish demand for this workflow.
Explore what works today
The demo shows how a small approved slice changes the answer.