Your IdP Proves Who. OpenController Decides What.

Enterprise AI agents need more than a valid login. They need an identity that can be verified, permissions that reflect what they are allowed to do, and controls that remain in place wherever they run.

That becomes harder when agents span teams, projects, models, knowledge bases, memory services, and cloud environments. A token can be valid but still belong to the wrong application. A gateway can reject an unauthorized request while a downstream service remains exposed. And a secret copied into the wrong place can undermine the isolation the rest of the platform is designed to provide.

OpenController, Lyzr’s control plane for enterprise agents, separates these responsibilities. Your identity provider establishes who a person, service, or agent is. OpenController registers agents and governs their access. Runtime services verify identity and enforce the rules where requests are handled.

This article explains how that model works, from onboarding an agent to checking its identity at runtime.

The agent identity record: what teams need to see

An agent should not be an anonymous process hidden somewhere in a deployment. It should have a clear owner, a version, a team, a project, and a record of how it was provisioned.

For example, an invoice-processing agent might appear in OpenController with details such as:

Its onboarding history can then record events such as repository creation, identity provisioning, certificate issuance, directory-group linking, namespace preparation, and secret-reference registration. If a model subscription is still waiting for approval, that pending step should be visible too.

This event-by-event record is useful for more than troubleshooting. It lets platform and security teams see what has actually happened, what remains incomplete, and where a process stopped, without piecing together the story from multiple consoles.

OpenController was developed around enterprise onboarding across Okta and workloads deployed in AWS and Azure. The design described below keeps the identity provider, control plane, and runtime responsibilities separate while allowing them to work together.

Bring your own identity provider

OpenController does not replace an enterprise identity provider (IdP). The IdP remains responsible for issuing identities and tokens. OpenController and the runtime services use those verified identities to apply platform-specific access rules.

The integration covers three kinds of callers.

People: map existing roles to console access

The console uses standard OIDC with PKCE. Roles can come from directory groups or an existing enterprise role-based access control (RBAC) service. Administrators can access the full registry, while developers can be limited to their own self-service functions. If a signed-in person has no mapped role, the console should make that lack of access explicit rather than silently granting a default role.

1. Services: verify the calling application

Machine-to-machine access uses client-credentials tokens. Each permitted client ID maps to a named service. That means an onboarding callback is checked against the expected onboarding service, not accepted simply because its token was issued by a trusted provider.

2. Agents: give each agent its own identity

Each agent receives a non-human identity in the IdP. Its token is then verified by the runtime services it calls. This avoids treating every agent as the same shared application and gives the platform a way to distinguish one agent from another.

OpenController is tested with Okta, including setups that separate non-production and production into different Okta organizations. Its services validate tokens from standards-based OIDC issuers using their published signing keys, so other compatible providers, such as Microsoft Entra ID or Keycloak, can follow the same model. Claim locations can be configured with JSON Pointers, for example, /AppProfile/project_id, to map an organization’s token structure to teams and projects without code changes.

How the control plane and runtime work together

A control plane needs a reliable picture of what exists, but runtime services need to enforce access close to the resources they protect. OpenController separates those jobs.

OpenController is the source of truth for registered agents, teams, projects, model providers, routes, and subscriptions. Each data plane receives a signed catalog snapshot and imports that state as a transaction. This helps keep deployments aligned with the approved configuration.

Data planes are identified by cloud, region, and environment—for example, {cloud}-{region}-{env}—and each has its own vault. OpenController sends secret references, such as kv://…, rather than distributing secret values in the catalog. The runtime resolves those references from its own vault when needed.

Writes to a data plane are designed to be idempotent. If a plane has fallen behind the control plane, it can report a 409 catalog_behind response instead of proceeding as though its state were current.

This architecture allows an agent to run across environments such as AWS and Azure while keeping the same identity and access principles in place. The deployment can vary; the rules should not.

Provisioning an agent, step by step

OpenController maps agent workspaces to familiar enterprise structures. A team corresponds to a directory group, a project represents a use case, and each project gets its own namespace. Each agent has its own registry entry and identity.

A typical onboarding flow looks like this:

1. Create the repository. Start from a standard template for the agent type, such as a domain agent, orchestrator, or tool, and its framework, such as LangGraph or CrewAI.
2. Request the agent identity. The identity provider, often through an onboarding service, creates a non-human identity. OpenController checks the name and can recover from a lost callback by looking up the agent.
3. Issue a certificate. Certificate issuance can complete asynchronously. The callback is tied to the relevant agent and onboarding attempt.
4. Link the directory group. Reuse the team’s group if it already exists; create it when necessary.
5. Prepare the namespace and workload role. Assign a workload role to the individual agent so one agent cannot read another agent’s secrets.
6. Register secret references. Store references to secrets in the platform record. Where a value must be stored, seal it before persistence.

Each step reports its own result to the onboarding ledger. That matters when a workflow partially succeeds: instead of showing only a broad “failed” status, the record can identify the specific step that needs attention. The console should also distinguish automated work from steps that still require a person, rather than implying that manual actions happened automatically.

After publication, the registry can serve an authenticated A2A agent card containing details such as the agent’s team, owner, version, stage, framework, and autonomy tier.

Subscriptions decide what an agent can use

Authentication and authorization solve different problems.

Authentication answers, “Who is making this request?” Authorization answers, “What is this caller allowed to use?” A valid identity token should not automatically grant access to every model, knowledge base, or memory store.

In OpenController, an application requests a subscription to use an agent or model. The owning team approves the request, and that approval creates a gateway key associated with the relevant team, project, and agent. The identity provider establishes the caller’s identity; the platform’s subscriptions and explicit grants determine the resources it can access.

Keep identity-provider scopes coarse

Scopes represent service capabilities, not every individual resource. Examples include:

• model:llm-router
• rag:<workspace>:query
• memory:<workspace>:write

Specific knowledge bases, model access, and budgets are governed through team and project tenancy plus explicit grants. Creating a knowledge base therefore does not require creating a new identity-provider scope. That keeps the IdP’s scope catalog manageable as the number of agents and resources grows.

Preserve the initiator’s permissions and budget

Access should not expand as work moves through a chain of agents. The application that initiates a request determines the budget context, while the agent calling a model is restricted to the models allowed for that call. A downstream agent should not gain more access than the caller that invoked it.

This is especially important for multi-agent workflows: every handoff needs to preserve the original authorization context instead of allowing each step to accumulate broader privileges.

What runtime services enforce

The control plane defines and distributes the approved state. The runtime must still check requests at the point where resources are accessed.

These checks should not depend solely on a perimeter gateway. The service that holds the data must verify the identity and tenancy claims itself. Otherwise, a request that bypasses one layer could reach a downstream resource without the intended checks.

Request content is also kept out of logs and trace payloads by default for knowledge-base and memory services, reducing the risk of sensitive content being copied into diagnostic systems.

Fit the enterprise’s existing runtime

Some enterprises already distribute a runtime library with every agent repository. That library may check policy with Open Policy Agent (OPA) before a tool runs, retrieve secrets from a vault, and exchange tokens for outbound calls.

OpenController is designed to work with that pattern rather than requiring teams to rewrite their agents around a Lyzr-specific library. Agents can remain standard LangGraph or CrewAI code, and the runtime backend can be changed through configuration.

For calls to Lyzr services, the runtime can use OAuth 2.0 Token Exchange, defined in RFC 8693. The exchanged token retains the person as sub and identifies the acting agent under act.sub. That lets records distinguish the human who initiated the work from the agent that performed a particular action, without trusting identity fields supplied in the request body.

Lessons from implementation

Identity integrations often fail at the edges between components. Several practical lessons shaped this design.

1. A valid token is not necessarily the right token

Two applications on the same Okta authorization server can receive tokens that look similar but differ in claims such as cid and sub. A gateway key must not bypass token validation. Binding keys to approved client IDs helps close that gap.

2. Validate the claims your provider actually issues

Okta places scopes in the scp claim. A check that reads only scope can therefore fail even when a token is valid. Test against real tokens from the actual tenant, not only locally constructed examples.

3. Verified claims must take precedence over request headers

A caller should not be able to change its effective team or tenant by sending different tenant headers alongside a valid token. Derive tenancy from verified claims and reject conflicting or untrusted context rather than allowing headers to override it.

4. Keep local tests aligned with production

A local configuration that omits an authentication setting can make development appear to work while concealing a production issue. Test configurations should reflect the security behavior of deployed environments.

5. Treat onboarding callbacks as security-sensitive

Callbacks can carry sensitive information and change provisioning state. Bind each callback to one agent and one attempt, accept it only from the expected onboarding service identity, and store secret references instead of exposing values.

Agent identity implementation checklist

Use this checklist when reviewing an enterprise agent platform:

• Keep identity and authorization separate. The IdP verifies who the caller is; subscriptions and grants determine what it can use.
• Give every agent its own identity and namespace. Use a dedicated workload role so secrets and permissions are isolated.
• Record every onboarding step. Make successes, failures, pending work, and manual steps visible in an event ledger.
• Distribute references, not secret values. Let each data plane resolve secrets from its own vault.
• Bind gateway keys to approved client IDs. Never treat possession of a key alone as proof of identity.
• Verify identity at the service that holds the data. Do not rely exclusively on checks at the gateway or network edge.
• Derive tenancy from verified claims. Do not let caller-controlled headers override the authenticated context.
• Preserve the initiating identity across agent handoffs. Keep the human and acting agent distinguishable in the authorization chain.
• Test with real provider tokens and production-like configuration. Confirm claim names, issuer validation, and environment boundaries.
• Make model retirement explicit. Notify dependent teams early and define what happens when a model is no longer available.

What’s next for OpenController agent identity

The next stage of the work is to extend full on-behalf-of support across services, checking the act chain at each hop and applying the initiator’s budget automatically.

The team is also working to automate remaining onboarding steps as identity providers expose the necessary APIs, starting with workload roles and pod identity.

The principle remains the same: identity needs to be verifiable, access needs to be explicit, and enforcement needs to happen wherever an agent acts, not only where it first enters the platform.

OpenController is Lyzr’s control plane for enterprise agents. It runs on your infrastructure and works with your identity provider.

Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here