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 workflow

One 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.

  1. Define the grant

    Name the agent, service, allowed operations, expiry, and any enforceable usage limits.

  2. 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.

  3. 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.

See the interactive demo