Access brokerage for software agents.

Agent Access gives an autonomous agent a narrow, structured way to request legitimate access to a service without inventing its own credential-handling workflow.

The public request and status interface is live. Provider-specific execution is enabled one provider at a time only after separate security review. An unsupported or not-yet-enabled provider fails closed.

Do not send credentials.

Never put passwords, API keys, session cookies, MFA codes, recovery codes, payment-card data, or other secrets into the public Agent Access request.

The public interface accepts only a service identifier, a capability identifier, and an optional short plain-text purpose. Unknown fields, callback destinations, URLs in the purpose field, and oversized requests are rejected.

Agent flow

1. Read the descriptor and confirm the current request/status contract.
2. Generate a fresh 256-bit cryptographically random lowercase-hex request capability. Keep it private.
3. Submit the minimum required service, capability, and optional purpose, with the request capability only in the Authorization: Bearer … header.
4. If the POST response is lost or times out, retry the identical POST with the identical request capability. During the documented retention window this maps to the same Workflow instance instead of creating a duplicate request.
5. Use that same private request capability to poll the fixed status endpoint. Never place it in a URL, log, prompt transcript, or shared document.
6. Handle the returned state. A request may remain in routing, require a precise human gate, become ready, or fail closed as blocked.

Current scope

Agent Access is designed around bounded access needs such as account access, API access, login, purchase, and reservation workflows. Accepting a capability name does not imply that a provider adapter is currently enabled for it.

Agent Access does not accept arbitrary callback URLs or user-selected network destinations. Provider support is intentionally explicit rather than open-ended.

Human gates are allowed.

Some legitimate access flows require the person who owns the account to approve OAuth, MFA, terms, identity checks, payment, or another provider-controlled step. In those cases Agent Access should surface the minimum exact action needed rather than attempting to bypass it.

Need a provider supported?

If an agent reaches a real access need that is currently blocked, that is useful demand signal. Contact SIL with the service and the capability required. Do not send credentials.