feat: add a core agent identity blueprint contract with Okta and Entra references

Problem Statement

OpenShell experiments for Okta gateway login, runtime provider refresh, RFC 8693 token exchange, and Cross App Access established useful agent identity flows, but landing vendor-specific implementations directly in OpenShell would make the runtime own integration policy, deployment, and lifecycle for every identity provider.

NemoClaw is the opinionated blueprint layer that already composes OpenShell provider profiles, policy, credentials, sandbox lifecycle, and agent packaging. It should provide the supported reference architecture for agent identity instead. Today it has bundled static provider profiles and robust provider lifecycle handling, but no complete reference that separates and composes:

application-user authentication and consent;
OpenShell gateway administrator or automation authentication;
backend service identity for sandbox and provider management;
sandbox workload identity;
delegated user credentials for an agent calling an approved API on behalf of that user.

Without a reference, integrations tend to reuse the gateway login token as the delegated subject, put OAuth custody in an ad hoc sidecar, or expose bearer material to the agent. The existing ID.me beta and NemoClaw Community Entra/Graph example demonstrate the desired identity boundaries, but they use standalone deployment and token-manager machinery that should become a repeatable NemoClaw shape.

Desired Behavior

NemoClaw core owns a versioned, provider-neutral agent identity reference contract. Okta and Microsoft Entra are its first product-owned conformance implementations, not an exclusive support boundary. ID.me, Ping, Palo Alto Networks, XAA.dev, and other standards-based providers are eligible for core when they satisfy the same product scope, ownership, lifecycle, compatibility, security, validation, and conformance requirements. NemoClaw Community remains an optional incubation path rather than the default destination for providers outside the first two implementations.

An operator can select a conforming reference and obtain a complete, inspectable deployment that uses OpenShell primitives for provider custody, policy-derived egress, credential injection, and middleware enforcement.

Each reference must keep these principals separate:

The application user authenticates with the IdP and consents to a bounded downstream API scope.
The application backend authenticates to the OpenShell control plane with its own service identity and manages only its authorized providers and sandboxes.
OpenShell administrators authenticate to the gateway through a separate OIDC client and role/scope mapping. Gateway login is optional for the delegated runtime flow and is never used implicitly as the application's subject token.
The sandbox supervisor uses its OpenShell-issued sandbox identity.
The agent receives only an OpenShell placeholder. It never receives an access token, refresh token, ID token, client secret, private key, or gateway administrator token.

For each of Okta and Entra, the reference should provide one concrete end-to-end workflow:

configure generic OpenShell gateway OIDC claim mapping for the provider;
complete an application-user authorization flow outside the sandbox;
transfer the current access token, expiry, and refresh/delegation material into an explicitly user-scoped OpenShell provider;
import a bundled Providers v2 profile that owns the exact API endpoints, L7 rules, allowed binaries, credential placement, and refresh/token-grant metadata;
attach the provider to one sandbox through NemoClaw lifecycle state;
call an approved downstream API through the OpenShell proxy with the current delegated credential injected after middleware;
rotate or exchange the credential without changing the agent-visible placeholder;
revoke and delete the user-scoped provider on logout, consent withdrawal, timeout, ownership change, or sandbox removal;
expose secret-safe provider refresh status, middleware findings, and OpenShell OCSF audit evidence.

The references should use the supervisor middleware contract from NVIDIA/OpenShell#2027 in substantially its current shape:

middleware runs after network/L7 admission and before provider credential injection;
it receives request, sandbox, and originating-process context but not OpenShell-managed credentials;
it may allow, deny, transform admitted content, emit findings, and add only approved namespaced headers;
Authorization, cookies, credential headers, routing headers, and framing headers remain protected;
the identity policy stage defaults to fail_closed for matching protected API hosts.

Middleware should enforce request-aware identity policy and produce non-secret context. Providers v2 remains the only component that mints, stores, refreshes, resolves, and injects credentials. Do not return bearer tokens in middleware metadata, findings, body mutations, or namespaced headers.

Constraints and Non-goals

Assume feat(supervisor-middleware): add network egress middleware OpenShell#2027 lands in relatively its current shape. Pin the first compatible OpenShell release in the blueprint and remove the pin only through the normal compatibility process.
Current Providers v2 supports OAuth2 refresh-token and client-credentials refresh plus SPIFFE JWT-SVID token grants, but not a general request-aware RFC 8693 OBO source. feat(providers): add dynamic identity sources to Oauth2TokenExchange strategy OpenShell#1736 tracks dynamic identity sources for token exchange. The reference must either depend on the smallest accepted upstream capability from that issue or clearly stage OBO as blocked; it must not add an Okta-only or Entra-only token-exchange engine to NemoClaw.
Current middleware cannot write Authorization and has no credential-resolution result. Preserve that boundary. If request-derived context must select a delegated grant, propose a non-secret handoff from middleware to Providers v2 or a separate credential resolver contract in OpenShell.
Do not capture the OpenShell CLI gateway-login token as delegated provider material. The application-user flow and control-plane login flow are independent even when the same human and IdP participate in both.
Core eligibility is based on conformance and sustained ownership, not provider market position. Okta and Entra establish the contract first; subsequent providers may land directly in core when their proposal names an owner and proves the same lifecycle, security, compatibility, validation, and maintenance commitments. NemoClaw Community may incubate incomplete or independently maintained variants but is not a permanent second-class tier.
Do not create a public NemoClaw plugin SDK, arbitrary executable extension point, identity CRD, custom controller, or vendor-specific OpenShell authentication subsystem.
Do not claim production certification for an IdP tenant. Local mock services and browser flows are acceptance tools; production requires HTTPS, durable encrypted state, tenant isolation, revocation, audit export, backup/recovery, and IdP-specific review.

Implementation Idea

Use existing repository-owned seams before adding a new abstraction:

Add reviewed Okta and Entra Providers v2 profiles under nemoclaw-blueprint/provider-profiles/. Follow the existing Brave and Tavily import-before-create path. Profiles contain no secrets and declare only destination-specific credential placement, refresh/grant metadata, endpoint policy, and allowed binaries.
Add a strict, repository-owned identity-reference manifest consumed by the existing blueprint plan/apply path. It should compose an identity flow, IdP adapter, resource profile, deployment profile, and reference scenario while naming the provider profile, gateway OIDC mapping, external middleware service registration, policy attachment, provider ownership, and cleanup behavior. Treat it as an internal data contract until at least Okta and Entra prove the same fields are needed; do not expose arbitrary executable hooks or promise a public plugin SDK.
Package the identity policy/broker service as a reviewed NemoClaw component reachable by both the gateway and sandbox supervisors. Register it statically in the OpenShell gateway TOML as required by feat(supervisor-middleware): add network egress middleware OpenShell#2027, start it before the gateway, and include it in health, reconcile, rebuild, and removal behavior. Service upgrades must restart the gateway and reconcile running supervisors; do not assume an in-place service change at the same endpoint refreshes cached manifests.
Keep application OAuth bootstrap outside the sandbox. For a local reference, use a minimal host service or reference application that completes Authorization Code + PKCE or device authorization, validates issuer/audience/nonce/state, maps the immutable subject to an opaque provider name, transfers custody to OpenShell, and clears its local token bundle after successful transfer.
Extend NemoClaw's provider lifecycle state to preserve the selected profile, opaque provider name, attachment, middleware registration, and non-secret identity configuration across rebuild and restore. Never persist raw token material in NemoClaw host state, manifests, generated config, logs, or backups.
Use one mock standards-compliant IdP/resource server test fixture for deterministic CI, then retain separate manual acceptance checklists for real Okta and Entra tenants.

The initial implementation should define the smallest internal composition contract needed by two explicit references, not a public provider plugin framework. Okta and Entra prove that the contract is provider-neutral. Further IdPs should add data-only adapters and resource profiles wherever the standards permit, with code reserved for genuinely distinct protocol behavior.

Acceptance Criteria

Alternatives Considered

Land each IdP in OpenShell. Rejected because generic OIDC gateway authentication, supervisor middleware, and Providers v2 are the reusable runtime primitives. Vendor deployment, consent, lifecycle, and reference application choices belong in the blueprint layer.

Route providers to core or community by vendor. Rejected because provider popularity is not an architectural boundary. Core support does imply lifecycle, compatibility, security, validation, and ownership commitments, so admission remains deliberate; however, any provider that satisfies those requirements can be maintained in core. Community is useful for incubation and independent ownership, not as the default home for every provider after Okta and Entra.

Let middleware mint and inject bearer tokens. Rejected because NVIDIA/OpenShell#2027 intentionally runs before credential injection, omits protected headers, and forbids Authorization mutation. Mixing policy inspection with secret-bearing credential injection would weaken the trust boundary.

Reuse the OpenShell gateway login token for OBO. Rejected because control-plane authorization and application-user delegation have different audiences, scopes, storage, revocation, and ownership. The ID.me reference demonstrates the safer separation.

Keep an opaque token-manager sidecar per integration. Useful as prior art and a temporary community implementation, but not the target. It duplicates provider custody, refresh, policy, observability, and recovery already owned by OpenShell.

Agent Investigation

Reviewed the ID.me OpenShell Minikube beta (NVIDIA-dev/idme-openshell-minikube-demo). Its strongest reusable contract is separation of application user, gateway administrator, backend service, sandbox supervisor, and agent identities, followed by explicit delegated credential custody transfer into OpenShell.
Reviewed stale OpenShell PRs feat(auth): add Okta workforce gateway login OpenShell#1672 (Okta gateway login), feat(providers): add Okta runtime provider profile OpenShell#1673 (Okta runtime refresh profile), feat(auth): support live Okta OBO token exchange OpenShell#1681 (Okta RFC 8693 OBO), and feat(xaa): add sample xaa provider flow OpenShell#1682 (Okta/XAA sample). Their provider profiles and tutorials are useful input, but feat(auth): support live Okta OBO token exchange OpenShell#1681 and feat(xaa): add sample xaa provider flow OpenShell#1682 couple delegation to the gateway-login subject token and add provider-specific refresh strategies that should not be copied into NemoClaw.
Reviewed feat(supervisor-middleware): add network egress middleware OpenShell#2027 and RFC 0009. The current API is an ordered HttpRequest/pre_credentials policy and transformation hook with static external-service registration, host selectors, body limits, strict header protections, findings, and fail-open/fail-closed behavior. It is a policy/context seam, not a credential provider API.
Reviewed Providers v2 in current OpenShell. It already supplies custom profile import/update, provider-owned network policy, attach/detach lifecycle, refresh material custody, short-lived credential rotation, dynamic SPIFFE token grants, and proxy injection. The missing OBO capability is dynamic user/actor identity sourcing, tracked by feat(providers): add dynamic identity sources to Oauth2TokenExchange strategy OpenShell#1736.
Reviewed current NemoClaw origin/main. The closest core precedent is nemoclaw-blueprint/provider-profiles/ plus src/lib/actions/credentials-add.ts and src/lib/onboard/brave-provider-profile.ts, which import bundled data-only profiles before provider creation and preserve provider lifecycle through onboarding/rebuild.
Reviewed NVIDIA/nemoclaw-community. examples/personal-community-sentiment-triage/ is the closest full reference architecture: explicit host services, gateway, providers, sandbox, policy, agent assets, bring-up/tear-down, and Entra/Graph token-manager lifecycle. It is useful packaging precedent and demonstrates behavior that core references can simplify with Providers v2.
Searched NemoClaw issues for Okta, OBO, OAuth, and identity-provider references. No existing issue covers this proposal; closed feat: add azure-nim inference profile for Microsoft Foundry-hosted NIM endpoints #58 concerns Azure-hosted inference rather than delegated agent identity.

Category

Provider

🏗️ build-plan

Implementation Plan

Issue type: feat
Complexity: High overall; Medium for the first slice
Confidence: Medium; the current-capability path is clear, but product ownership and upstream OBO remain unresolved

Scope Decision

All standards-based identity providers are eligible for NemoClaw core. Okta and Entra are the first conformance implementations, not an exclusive boundary. Additional providers require maintainer approval, ownership, compatibility documentation, and the same conformance evidence. NemoClaw Community is an optional incubation path, not the default destination.

Maintainers must accept this revised product scope before implementation begins.

Minimal First Slice

Ship a current-capability delegated-credential reference for Okta and Entra:

Application authentication and consent remain outside the sandbox and outside NemoClaw.

A repository-owned reference runner accepts an existing access token, expiry, refresh token, and client configuration through named environment variables.

It renders and imports a data-only Providers v2 profile, creates an opaque user-scoped provider, configures oauth2_refresh_token, and attaches it to one named sandbox.

Entra demonstrates GET https://graph.microsoft.com/v1.0/me; Okta demonstrates its OIDC userinfo endpoint unless maintainers choose another concrete resource.

The agent receives only the OpenShell placeholder. Apply failures roll back resources created by that invocation; remove detaches before deleting.

The slice explicitly does not implement RFC 8693 OBO, request-derived provider selection, an OAuth browser application, or a production identity middleware service.

Middleware NVIDIA/OpenShell#2027 remains the request-policy boundary: post-admission, pre-credential, no credential visibility, protected Authorization, namespaced non-secret headers, and fail_closed for protected hosts. Providers v2 alone owns token custody, refresh, and injection. Request-aware OBO remains blocked on NVIDIA/OpenShell#1736 or an equivalent generic resolver contract.

Exact Scope

Source and data

nemoclaw-blueprint/identity/okta.yaml: built-in, data-only Okta reference definition.

nemoclaw-blueprint/identity/entra.yaml: built-in, data-only Entra reference definition.

schemas/agent-identity-reference.schema.json: strict internal schema; no external discovery or SDK commitment.

scripts/lib/agent-identity-reference.ts: validate tenant/issuer inputs, render the Providers v2 profile, and construct secret-safe OpenShell operations.

scripts/agent-identity-reference.ts: explicit plan, apply, status, and remove reference workflow.

scripts/validate-configs.ts: discover and validate the two built-in definitions.

Documentation

docs/security/agent-identity.mdx: five-principal trust model, supported refresh-token workflow, OBO limitation, rotation, revocation, and troubleshooting.

docs/reference/architecture.mdx: identity reference topology and OpenShell/NemoClaw ownership boundaries.

docs/resources/community-contributions.mdx: replace provider-default routing with conformance-based core eligibility while preserving the product scope gate.

docs/index.yml: publish the identity security page.

Tests

test/agent-identity-reference.test.ts: schema, rendering, allowlists, URL validation, and secret-negative unit tests.

test/agent-identity-lifecycle.test.ts: ordered import/create/refresh/attach and detach/delete rollback behavior.

test/e2e/fixtures/agent-identity/: mock OAuth token and protected-resource services.

test/e2e/support/agent-identity-reference.test.ts: deterministic OpenShell lifecycle support tests.

test/e2e/live/agent-identity-reference.test.ts: opt-in mock-backed sandbox proof; real Okta and Entra remain manual acceptance.

Do not change the main onboarding state model, add a public adapter registry, or add arbitrary executable hooks in this slice.

Implementation Steps

Revise the documented product rule and define the closed, strict internal shape consumed only by the two built-in references.

Add Okta and Entra data definitions and validate issuer hosts, tenant values, scopes, resource endpoints, binaries, and required refresh material.

Implement a dry-run plan that shows non-secret resources and operations without exposing token material.

Implement apply/remove with access tokens passed through --credential ENV_NAME, refresh tokens through --secret-material-env, a minimal subprocess environment, and compensating cleanup.

Prove profile import, provider refresh, single-sandbox attachment, placeholder-based API access, rotation, revocation failure, and cleanup against local mock services.

Publish the trust model, present limitations, version requirements, and provider admission criteria.

Test Plan

Unit: Reject unknown fields, unsafe issuer/token URLs, wildcard resource hosts, invalid scopes, provider-name collisions, inline secrets, secret-bearing diagnostics, unsupported grants, and any RFC 8693 parameters. Verify exact least-privilege methods, paths, and binaries.

Integration: Verify import precedes create, refresh precedes attach, only one sandbox is targeted, rotated refresh material remains secret, failures compensate in reverse order, and remove never detaches a same-name provider with mismatched identity.

E2E: Run both definitions against mock OAuth/resource servers through a real OpenShell sandbox. Assert placeholder-only sandbox surfaces, current refresh semantics, revoked-token failure, deterministic teardown, and negative scans of argv, environment dumps, logs, generated files, snapshots, and backups. Real-tenant Okta and Entra checks are manual and must record no tokens or personal data.

Risks and Open Questions

Current static placeholder injection is not endpoint-and-binary scoped, even though provider-derived policy is. The reference must not claim stronger isolation than Providers v2 supplies.

Running processes may need to be relaunched to receive a new revision-scoped placeholder after refresh. The first slice must document and test current behavior.

The exact Okta protected resource and supported authorization-server topology need a product decision.

NemoClaw must decide whether a later phase owns an OAuth bootstrap application or accepts custody transfers from application backends.

A later middleware service needs explicit ownership, authentication, deployment, availability, and upgrade behavior. Service changes require gateway restart and supervisor reconciliation because feat(supervisor-middleware): add network egress middleware OpenShell#2027 caches manifests.

Core eligibility does not imply automatic acceptance. Every new IdP still passes NemoClaw's product scope, security, lifecycle, compatibility, and ownership gates.

Configuration and Platform Impact

Gateway configuration docs: No gateway.toml change in this slice, so no gateway configuration reference update is required. A later packaged middleware service must document [[openshell.gateway.middleware]], service-before-gateway startup, static restart, supervisor reconciliation, and the compatible OpenShell release.

SELinux/AppArmor: No expected impact. This slice does not inspect /proc, change process identity, execute sandbox system binaries, add mounts, or alter LSM policy. Future middleware containers or host services require a separate SELinux/AppArmor assessment.

Reviewed against NemoClaw origin/main at 20130dd4.

@afourniernv

✨ Thanks for the proposal, @afourniernv. This is a significant cross-cutting reference architecture for agent identity. Before implementation, maintainers need to align on the scope, composition model, and which Okta/Entra flows the initial blueprints should cover.

Scope alignment proposal after upstream middleware merge

I revalidated this proposal against NemoClaw origin/main at 7d1cef9d and the current
OpenShell dependencies:

feat(supervisor-middleware): add network egress middleware OpenShell#2027 merged on 2026-07-17. The supervisor middleware contract is now
available rather than hypothetical.
feat(providers): add dynamic identity sources to Oauth2TokenExchange strategy OpenShell#1736 remains open in triage. Request-aware identity sourcing and RFC
8693 OBO should therefore remain outside the first slice.
NemoClaw now has a dedicated credential-provider registration seam in
src/lib/onboard/credential-provider-registration.ts; the first slice should reuse the
existing provider registration and lifecycle contracts rather than create a parallel
registry.
The configuration validator is now scripts/validate-configs.mts.

To make the remaining product decision explicit, I recommend the following alignment:

Core scope: NemoClaw owns a provider-neutral, repository-internal agent identity
reference contract. Okta and Entra are the first product-owned conformance references.
Other standards-based providers remain eligible for core only with a named owner and
equivalent lifecycle, security, compatibility, validation, and maintenance evidence.
Initial flows: The first slice accepts OAuth material obtained by an application
outside NemoClaw. Entra proves GET https://graph.microsoft.com/v1.0/me; Okta proves
the OIDC userinfo endpoint. Gateway administrator login remains independent from
application-user delegation.
Composition model: Use two built-in data definitions, a strict internal schema,
data-only Providers v2 profiles, and explicit plan, apply, status, and remove
operations. Reuse current provider registration, attachment, rebuild, and cleanup
seams. Do not add a public plugin SDK, arbitrary hooks, an identity CRD, or a custom
controller.
Phasing: The first slice proves current refresh-token custody, placeholder-only
agent access, one-sandbox attachment, rotation, revocation failure, and deterministic
cleanup. It does not ship an OAuth browser application, request-derived provider
selection, RFC 8693 OBO, or a production identity-policy middleware service. A later
slice can use the merged middleware contract for request-aware policy while preserving
the pre-credential boundary.

The specific decisions needed before implementation are therefore:

accept or revise the provider-neutral core eligibility rule;
accept userinfo and Microsoft Graph /me as the first concrete resource flows;
accept application-supplied OAuth custody transfer as the first bootstrap boundary;
accept the phased exclusion of OBO and a production middleware service.

If those four decisions are accepted, the implementation can proceed as a bounded first
slice without waiting on NVIDIA/OpenShell#1736. If maintainers want middleware or OAuth
bootstrap in the initial deliverable, the issue should remain needs: design and the
deployment and ownership model should be specified before code begins.

Initial implementation is now split by ownership:

NemoClaw reference slice: feat(blueprint): add Okta runtime identity reference #7265 adds the Okta and Entra direct-blueprint refresh references, profile templates, middleware configuration validation, and trust-boundary documentation.
Generic OpenShell CLI fix: fix(cli): support fixed OIDC callback ports OpenShell#2375 adds fixed OIDC callback-port support only. It intentionally contains no IdP profiles or vendor integration.

The Entra reference has deterministic unit and configuration coverage. Live Entra validation remains pending because the previous tenant is unavailable. OBO remains intentionally staged behind the generic upstream identity-source capability described in this issue.

Correction: draft PR #7265 is now the Okta-only reference slice. Microsoft Entra has been removed from that PR and remains tracked in this issue for a later companion reference. OBO remains deferred pending a generic dynamic actor-credential source in the platform.

feat(blueprint): add Okta runtime identity reference (#7265)

Maintainer decision: accept the bounded Okta and Entra runtime identity references

I am recording the maintainer product decision for this issue.

The following first-slice scope is accepted:

NemoClaw core owns a provider-neutral, repository-internal runtime identity contract. Okta and Microsoft Entra are the first built-in conformance references, not a vendor-specific public extension framework.
Application authentication and consent remain outside NemoClaw. The application supplies existing delegated OAuth material for transfer into OpenShell custody.
The Entra reference is bounded to the reviewed Entra issuer and delegated Microsoft Graph GET /v1.0/me delivery surface. A data profile alone cannot expand token-issuer or credential-delivery trust.
OpenShell Providers v2 exclusively owns credential custody, refresh, rotation, placeholder resolution, injection, attachment, and deletion. NemoClaw owns plan/apply/status/remove orchestration, durable non-secret ownership state, compensation, rebuild/restore behavior, and documentation.
Browser OAuth bootstrap, RFC 8693 OBO, request-derived provider selection, production identity middleware, arbitrary hooks, and a public identity plugin SDK are outside this slice.

Ownership, compatibility, and security expectations are also accepted:

The NemoClaw maintainers own the built-in Okta and Entra references and their lifecycle, security posture, compatibility, tests, and documentation.
Compatibility follows the normal pinned OpenShell dependency and NemoClaw release process; incompatible OpenShell behavior must fail closed or be updated through that process.
The sandbox and agent receive opaque placeholders only. Token material, client secrets, gateway credentials, and tenant identifiers must remain absent from persisted state, logs, command evidence, snapshots, and backups.
Issuer, host, method, path, allowed-binary, provider-ownership, and cleanup boundaries remain code reviewed and fail closed.

The accepted validation contract is:

Exact-head deterministic PR E2E runs through the real OpenShell gateway/provider/sandbox path and an Entra-shaped public HTTPS fixture. It must prove refresh-token exchange and rotation, bearer delivery only to GET /v1.0/me, rejection before delivery for an unreviewed resource, placeholder-only sandbox surfaces, secret-safe evidence, ownership-aware rollback, and complete cleanup.
A separate secret-safe real-tenant acceptance check must prove that the configured delegated Entra token can refresh and call Microsoft Graph GET /v1.0/me for the authenticated principal.
Production tenant secrets are not required in CI. The deterministic full-path proof plus the real-tenant Entra/Graph contract check is accepted for this reference slice. This does not claim production tenant certification.

This decision clears the Product Scope Gate for the bounded implementation in #7686. The issue can remain open for later OBO, middleware, bootstrap, and broader conformance work, but those follow-ups do not block the accepted Entra reference.

feat(blueprint): add Entra runtime identity reference (#7686)

chore(deps): trust OpenShell 0.0.106 manifests (#9224)

chore(deps): update OpenShell to 0.0.106 (#9192)

This issue is being rescoped into new epics as part of the NemoClaw V1 planning review. The rescoped work will return in a few days.

Closing this issue for replanning, not because the work is complete.

Navigation Menu

Repository navigation

feat: add a core agent identity blueprint contract with Okta and Entra references #6871

Problem Statement

Desired Behavior

Constraints and Non-goals

Implementation Idea

Acceptance Criteria

Alternatives Considered

Agent Investigation

Category

Implementation Plan

Scope Decision

Minimal First Slice

Exact Scope

Implementation Steps

Test Plan

Risks and Open Questions

Configuration and Platform Impact

Scope alignment proposal after upstream middleware merge

Maintainer decision: accept the bounded Okta and Entra runtime identity references

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

feat: add a core agent identity blueprint contract with Okta and Entra references #6871

Description

Problem Statement

Desired Behavior

Constraints and Non-goals

Implementation Idea

Acceptance Criteria

Alternatives Considered

Agent Investigation

Category

Activity

afourniernv commented on Jul 14, 2026

Implementation Plan

Scope Decision

Minimal First Slice

Exact Scope

Implementation Steps

Test Plan

Risks and Open Questions

Configuration and Platform Impact

wscurran commented on Jul 14, 2026

afourniernv commented on Jul 17, 2026

Scope alignment proposal after upstream middleware merge

afourniernv commented on Jul 20, 2026

afourniernv commented on Jul 20, 2026

ericksoa commented on Jul 29, 2026

Maintainer decision: accept the bounded Okta and Entra runtime identity references

jyaunches commented on Oct 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions