Access and client apps

Understand memberships, grants, execution policy, and the people using agents inside your product.

An agent's definition describes what it can do. Access determines whether a particular person or application may run it and use its dependencies in the current environment.

The layers of access

Layer	What it controls
Organization and environment membership	Who can enter the scope and which management or building actions they can perform.
Resource grants	Whether a principal may use an agent, workflow, model, tool, skill, or collection.
Execution policy	Which model and execution behavior the environment permits.
Collection access	Who can read or manage knowledge, with any restriction to allowed agents.
API key or client session	The identity and authorized scope of an application's request.
Review requirements	Who can approve the particular proposed action while a run is waiting.

Publishing successfully does not prove that every user can run the result. A dependency may be configured correctly but unavailable to the person starting the run.

Check a published target

Open Access on the agent or workflow. Check for me checks the current person without starting work or calling the model. Owners and administrators can also check another principal or API key.

Review each blocking result. Checks cover the target, dependencies, policy, and limits; workflows also require their steps to be usable. Follow the provided links to fix the specific missing access, then check again.

Run a real test after the checks pass. Access checks do not prove that a provider credential is accepted or that an external service will return the expected data.

Roles and editing

Owners and administrators manage environment configuration and queues. Builders can build workflows and choose queue assignments where their permissions allow it. The current agent editor requires an owner or administrator to save and publish agent changes.

Permission to inspect a run is separate from permission to control it or respond to an approval. If a reviewer can see the proposal but cannot act, check the step's approver settings and that person's current access.

Make an agent available to your application

The agent or workflow's Client apps section gives it a name that your pages can call, such as request_assistant. Choose Make available after entering the name.

That name resolves to the latest published version. Unlike a schedule or a workflow step pinned to a version, a client-app target can therefore change behavior when you publish. Keep compatible input and output contracts, and test changes before exposing them to users.

Renaming the target means updating the pages that call it. Stop offering this removes that named entry point. Availability is only one part of access: the signed-in app user still needs the relevant authorization.

Your server authenticates the person using your product and creates a scoped client session. Browser components use that session; your server API key stays on the server. Map trusted user identity and roles on the server rather than accepting arbitrary browser claims.

Client-app configuration and grants determine what the application and its users can use. Configure allowed sites and roles as part of the integration. Use the embedding guide for setup and the React guide for chat, run, approval, and file components.

Start by offering one tested agent to one application role. Verify the experience as that user, including denied access and review steps, before expanding the set of available targets.