# Organization An Organization is the top-level tenant boundary in WSO2 Agent Manager. Every [Project](/agent-manager/docs/next/concepts/project/.md), [Environment](/agent-manager/docs/next/concepts/environment/.md), [Gateway](/agent-manager/docs/next/concepts/gateway/.md), and resource you register belongs to exactly one organization. Organizations aren't something Agent Manager owns or invents, they're managed by [OpenChoreo](https://openchoreo.dev), the platform Agent Manager is built on. Agent Manager is a control plane layered on top of OpenChoreo. So when you create an organization, you're creating the same organization OpenChoreo itself would recognize. ## What an Organization Contains[​](#what-an-organization-contains "Direct link to What an Organization Contains") **[Projects](/agent-manager/docs/next/concepts/project/.md)** are the containers your agents live in. Every agent belongs to exactly one project, and a project is also what a **[Deployment Pipeline](/agent-manager/docs/next/concepts/deployment-pipeline/.md)** attaches to — so the promotion path an agent follows is decided at the project level rather than per agent. An organization typically holds several projects, one per application or team. **[LLM Service Providers](/agent-manager/docs/next/concepts/llm-service-provider/.md)** and **[MCP Proxies](/agent-manager/docs/next/concepts/mcp-proxy/.md)** are defined at the organization level rather than inside a project, so any agent in any project can reference them. **[Environments](/agent-manager/docs/next/concepts/environment/.md)** and **[Gateways](/agent-manager/docs/next/concepts/gateway/.md)** are organization-level. An environment has at most one ingress gateway for inbound calls to its agents, and may have several egress gateways hosting outbound LLM and MCP traffic. Identity providers are attached to those gateways, and determine which token issuers each environment trusts. ## Access Control[​](#access-control "Direct link to Access Control") Access control in Agent Manager is defined at the organization level and nowhere else. Users, groups, and roles all belong to an organization, and a permission granted there applies across every project inside it. ### One Permission Model, Every Entry Point[​](#one-permission-model-every-entry-point "Direct link to One Permission Model, Every Entry Point") Every action in the organization is authorized against an OAuth 2.0 scope named `amp::`(ex:- `amp:project:read`, `amp:agent:build`, `amp:gateway:create`).Scopes are issued as claims on an access token by the platform's identity provider. The same scope gates the same capability whether you reach the platform through the Console, the REST API, or the MCP servers. The full catalog is in the [Authorization reference](/agent-manager/docs/next/reference/authorization/.md). note This platform identity provider is not the same thing as the per-environment identity providers described in [Environment](/agent-manager/docs/next/concepts/environment/.md). This one authenticates **people and service accounts against the control plane** — who may create, build, deploy, and promote. The per-environment providers are attached to gateways and govern runtime traffic which token issuers an environment trusts on calls reaching a running agent or proxy endpoint. ### Roles Bundle Scopes Around Personas[​](#roles-bundle-scopes-around-personas "Direct link to Roles Bundle Scopes Around Personas") You don't grant scopes one at a time. A **role** is a named bundle of scopes, and you assign it to a **user** or to a **group** — assigning through groups is how access is usually managed at any real size, since team membership changes far more often than the permission set a team needs. Agent Manager ships four predefined roles, each shaped around a job rather than around a resource: * **Agent Manager Admin** — everything, including the things nobody else can do like managing roles and groups, managing agent identities, and organization settings. * **Developer** — builds and ships agents. Full control over projects and agents, and consumes shared resources (connecting to LLM providers and MCP servers) without being able to register or change them. * **AI Lead** — owns the model and tool surface. Registers LLM providers, MCP servers, scopes, and evaluators for the whole organization, but only reads and builds agents rather than owning them. * **Platform Engineer** — owns the infrastructure. Environments, gateways, and deployment pipelines, plus the agent operations that touch production. The split between those last two is the useful part: an AI Lead governs *what agents may use*, while a Platform Engineer governs *where agents run*. Neither role can do the other's job, and neither has to wait on an admin to do their own. ### Production Is a Separate Permission[​](#production-is-a-separate-permission "Direct link to Production Is a Separate Permission") Deploying an agent isn't one permission it's two. `amp:agent:deploy-non-production` and `amp:agent:deploy-production` are distinct scopes, so a Developer can iterate freely in development and staging while production deployment, promotion, rollback, and suspension stay with Platform Engineers and admins. This is what makes a [Deployment Pipeline](/agent-manager/docs/next/concepts/deployment-pipeline/.md) a real control rather than a convention, the pipeline defines the path an agent takes through environments, and the permission split decides who is allowed to move it along that path. ### Administration Is Its Own Set of Permissions[​](#administration-is-its-own-set-of-permissions "Direct link to Administration Is Its Own Set of Permissions") Organization-level administration tasks like inviting or removing members, assigning roles, managing identity providers, managing service accounts are modeled as their own set of permissions (`amp:org:invite-member`, `amp:org:assign-role`, `amp:org:manage-idp`, and so on), kept separate from the permissions on the resources (agents, gateways, providers) inside the organization. Someone can be given full control over the agents in an organization without also gaining the ability to change who else has access to it. **Service accounts** cover the callers that aren't people. A CI pipeline that builds and deploys agents needs the same scopes a Developer has, but it can't go through an interactive login. A service account gives it its own identity and its own role assignment, so automated access is granted and revoked independently of any individual's account.