AUTHENTICATION
The implemented access model centers on agent API keys, signed or encrypted tokens, origin controls, and agent/context resolution.
This section reflects the access features actually documented and implemented for embedded PrintSpeak agents.
Feature family placeholder
Reserved for a dedicated interface preview, workflow diagram, or annotated screenshot.
MATRIX
Agent API keys
Includes
Each integration key has a `client_id`, `client_secret`, `default_agent_ref`, and `agent_mappings`.
Why it matters
This is the real authentication surface for embedded agents, not a generic end-user login matrix.
JWT tokens
Includes
Signed HS256 tokens with the `kid` header set to the public client ID.
Why it matters
Claims become verified agent context and cannot be tampered with client-side.
JWE tokens
Includes
Encrypted tokens using a SHA256-derived key from the client secret.
Why it matters
Sensitive embed context can be hidden from the end user, not merely signed.
Allowed origins
Includes
Per-key origin allowlists with wildcard support.
Why it matters
The system checks widget origin before allowing a token to be used on a site.
Agent reference routing
Includes
The `agent` claim resolves through `agent_mappings` and falls back to `default_agent_ref`.
Why it matters
That is the concrete mechanism for multi-agent external access control.
Internal context injection
Includes
API keys can inject enterprise, tenant, or user lookup context through `context_config`.
Why it matters
The embed surface is more than auth alone; it can attach scoped internal context server-side.
Recognized identity claims
Includes
Claims like `first_name` and `last_name` are explicitly recognized for personalized greetings.
Why it matters
This is narrower and more accurate than claiming broad profile sync or user provisioning.
Legacy public mode
Includes
A non-API-key JWE config-token mode still exists for public agents.
Why it matters
PrintSpeak supports both legacy public embedding and the newer authenticated SDK flow.
| Capability | Includes | Why it matters |
|---|---|---|
Agent API keys | Each integration key has a `client_id`, `client_secret`, `default_agent_ref`, and `agent_mappings`. | This is the real authentication surface for embedded agents, not a generic end-user login matrix. |
JWT tokens | Signed HS256 tokens with the `kid` header set to the public client ID. | Claims become verified agent context and cannot be tampered with client-side. |
JWE tokens | Encrypted tokens using a SHA256-derived key from the client secret. | Sensitive embed context can be hidden from the end user, not merely signed. |
Allowed origins | Per-key origin allowlists with wildcard support. | The system checks widget origin before allowing a token to be used on a site. |
Agent reference routing | The `agent` claim resolves through `agent_mappings` and falls back to `default_agent_ref`. | That is the concrete mechanism for multi-agent external access control. |
Internal context injection | API keys can inject enterprise, tenant, or user lookup context through `context_config`. | The embed surface is more than auth alone; it can attach scoped internal context server-side. |
Recognized identity claims | Claims like `first_name` and `last_name` are explicitly recognized for personalized greetings. | This is narrower and more accurate than claiming broad profile sync or user provisioning. |
Legacy public mode | A non-API-key JWE config-token mode still exists for public agents. | PrintSpeak supports both legacy public embedding and the newer authenticated SDK flow. |
RELATED FAMILIES
ENTERPRISE FEATURES
The real admin surface centers on agent creation, versioning, import/export, scope controls, and operational configuration inside the enterprise UI.
SDK
The implemented surfaces are a standalone widget script, a JS API, trigger elements, and internal Rails/Stimulus helpers.
WHITE LABEL
The external widget supports multiple themes, title overrides, display modes, and custom theme builds for branded deployments.