One accountable agent.
Explicit authority.

Keep these credentials separate

• Human sign-in: OIDC signs a person into an application. An app client secret is not a user identity or agent permission.
• Workload identity: an existing hcwc_… client belongs to an Identity owner and workspace. Its Ed25519 key signs short-lived assertions to obtain scoped hcw_… access tokens.
• Memory credentials: the existing memory-agent registry issues separate credentials and space grants. Linking two records requires ownership of both in the same workspace; names and email are never identity matches.
• Developer application automation: an app-management credential registers/configures SSO apps only. It does not grant personal profile, memory or spending access.

Register and connect an agent

1. Sign in to Hybrid-ID and open Agentic Identities. Create a context agent in a workspace you own, or use Hybrid-Chain’s AI Wallet Control to enroll an agent with commerce authority.
2. Download the private key once and keep it in the agent runtime’s secret store. Only the public JWK and a registration proof reach Identity. The context-agent form grants context:read and context:query; collection access remains separately controlled.
3. Use the existing workload integration guide for assertion construction, token exchange, request signatures and rotation. The published V2 contract remains authoritative for its supported operations.
4. For commerce, configure the exact network, operational wallet, policy version, limits and approval requirements in Hybrid-Chain. Successful authentication never creates spending authority.
5. If the same runtime has an existing memory-agent record, link it explicitly under Agentic Identities. This association grants no new resource access.

Management API boundary

The following are first-party Hybrid-ID portal APIs. They are not new public V2 bearer-token APIs and do not accept third-party OIDC access tokens. The browser uses its HttpOnly Hybrid-ID session and same-origin JSON requests; the BFF signs its requests to Identity.

The server-only Identity routes are GET/POST /identity/mobile/portal/agents and POST /identity/mobile/portal/agents/register. They require a signed gateway request and an Identity session bound to hybrid-id-web. The backend derives the owner and checks each existing record; caller-supplied owner, profile and role fields are rejected.

{
  "action": "publish",
  "client_id": "hcwc_YOUR_WORKLOAD_CLIENT",
  "operation_id": "32_lowercase_hex_characters",
  "code": "current_authenticator_code",
  "include_commerce": false
}

• Mutation actions: link_memory, unlink_memory, revoke_workload, revoke_linked_access, publish, withdraw. Link requests additionally specify memory_agent_uuid.
• Identity receives a purpose-bound step_up_token, not the browser’s code. An operation receipt binds the exact intent, identity and session. Completed retries return the recorded result. An ambiguous in-progress operation is not silently repeated.
• Registration uses the existing public-key proof and WORKLOAD_CLIENT_REGISTRATION authorization. It accepts tenant_uuid, label, allowed_scopes, public_key_jwk, proof and the step-up token. On uncertain registration results, refresh before creating another agent.
• Do not automate the owner portal by storing a person’s password or authenticator secret. Agent runtime APIs use scoped workload credentials and domain grants; autonomous owner-management delegation is not provided by these routes.

Revocation has a defined scope

• Workload revocation disables that client and its existing access tokens in the Identity authority. Services must recheck token status; downstream caches or already-running work may outlive the change.
• Linked-access revocation also attempts to remove the linked memory agent’s active credentials and owner-managed grants. Each component has its own result; unavailable services return UNCONFIRMED.
• Wallet budgets and pending executions remain in Hybrid-Chain. Pause or revoke wallet bindings there and review pending approvals. Revocation cannot reverse completed transactions.
• Unlinking a memory record only removes the association. It does not revoke either credential.
• Existing organization administration remains in its domain service. Agentic Identities lists records owned by the signed-in identity; it does not transfer ownership or elevate a workspace member.

Publish evidence deliberately

The owner approves a seven-day signed snapshot. It contains a per-agent pseudonymous owner/workspace reference, workload public key, scopes, status and optional commerce references. Publishing commerce links reveals wallet binding identifiers, policy references and up to 25 retained event references for each of at most ten bindings. No name, email, private key, token, raw memory or private rationale is included.

Evidence revisions are retained with a previous-digest link. Withdrawal removes the public lookup while preserving private history. External copies cannot be recalled. Publishing links can correlate otherwise separate records; review this disclosure before approval.

GET https://hybrid-chain.com/api/explorer/agents/{public_id} returns the signed publication and a separately signed current status observation. Obtain the public ID from its owner. Unpublished or withdrawn records return 404; a service failure returns 503. There is no public owner enumeration endpoint.

Verify each claim separately

1. Fetch trusted issuer metadata at the fixed issuer endpoint. Do not trust a key supplied only inside an untrusted evidence document.
2. For the publication and status independently, remove the proof property, serialize recursively sorted object keys as compact UTF-8 JSON, then verify the base64url Ed25519 signature using the issuer’s allowed assertion key. Check schema, issuer and expected public ID.
3. Compute SHA-256 over the complete signed publication in the same canonical JSON format. Match both the response digest and the status observation’s publication digest.
4. Check publication expiry, a fresh status observation, active workload status and key/scope/linkage changes. The explorer accepts status observations up to two minutes old with 30 seconds of clock skew; an application may require a stricter policy. These snapshots are evidence, not authentication tokens.
5. Follow the exact policy version to the existing budget proof and recompute its canonical commitment. Wallet activation and execution evidence require their own verification. Event references in the snapshot do not contain the complete Core event payload, so they alone cannot replay that event hash chain.

An issuer signature attests the recorded owner and grants at a point in time. It does not prove a legal identity, successful KYC, permission to read a particular resource, budget compliance, actual execution, settlement or on-chain anchoring. Do not turn a signed snapshot into a blanket authorization.