Apps call vendor APIs through named operations. The broker holds the secret, validates the grant, and returns a filtered response. Vendor credentials never enter the worker.

​
How a call is authorized

The SDK sends the workload token and, when present, the user token to the control-plane broker. Before anything reaches the vendor, the broker validates:
1

The grant

That this app has this operation on this connection.
2

The user-presence rule

Whether the operation requires a real signed-in user behind the request.
3

The input schema

The shape of what you passed.
4

The constraints

The security boundary — see below.
5

The rate limit

Per grant.
6

The response filter

What comes back, before your app sees it.
Every call is audited with a stable operation id.

​
Operation ids have exactly three parts

Concise operations are qualified with the capability name during normalization, so payments.read under name: stripe becomes stripe.payments.read. Three parts, because that is what the broker route (/v1/capabilities/:provider/:resource/:action) addresses.

​
The catalog

​
Constraints are enforced at call time

Constraints are the security boundary, and they are enforced when the call happens — not merely validated when the manifest is parsed.
Refuses a channel the grant does not name, and refuses @channel unless allowBroadcast is set.
Refuses a repository outside repositories.
Refuses a model outside models, and caps max_output_tokens at the granted ceiling.
Sends only from the granted address and, when recipientDomains is set, only to those domains.

​
The HTTP escape hatch

http.request.send is for an API with no dedicated integration, and it is deliberately not generic. The grant names the origins, the methods, and optionally the path prefixes; the app supplies only a request within them.
The broker injects the credential using the grant’s auth scheme into a header the app cannot set, read, or observe, and returns only the status and the payload — never set-cookie or upstream auth headers.
A grant with no origins reaches nothing at all. That is the safe default, not a misconfiguration to work around.

​
Setting up a connection

A connection is the organization-level object that holds the actual credential. Create it once, then apps reference it by name.
The credential is sealed with TINY_SECRET_KEY under a key derived per organization, and is never echoed by any API. A ciphertext cannot be moved between organizations.

​
Requesting and approving a grant

Requesting a capability never approves it, even for an admin, unless organization policy disables the requirement. A production capability request requires approval under the default policy.
Approve as an organization admin:
A capability the previous revision did not have triggers NEW_PRODUCTION_CAPABILITY on deploy. See Approvals. Preview environments skip capability approval — they get sandbox connections and an empty database, so the risk is different in kind. That is what makes previews useful to an agent.

​
Prefer this over direct egress

An app with direct egress holds whatever credential that endpoint requires. An app with a capability holds nothing. Whenever an operation exists, use it.