Security and identity reference architecture
The question from the review, and the one point Allvue called a red flag: not whether cortex can generate authentication code, but whether Allvue can enforce authentication, authorization and identity architecture centrally and consistently, at a platform level. OIDC, acting on behalf of a user, OAuth, container and customer boundaries, and no team inventing its own security pattern. Allvue defines the security architecture once; every generated service must conform to it.
The short answer
That is the right demand, and it is the shape cortex is built around: a generated service carries no security logic of its own beyond what its requirements say, and the platform supplies identity, authorization, secrets and audit around it. Today the platform enforces that for everything that runs through cortex (the chat, agents, workflows, the operations pages, the data call): identity is verified before anything runs, authorization is one shared fail-closed rule plus versioned row and column policies whose attributes can come from Allvue's own entitlement API, secrets are per project and never in code, and every change is an attributed commit. Available
For what runs as the application (an app service in Allvue's VPC), the security architecture is Allvue's, and cortex builds against it: Allvue's OIDC provider, Allvue's service identity, Allvue's gateway. Today that conformance is achieved the way every other requirement is: Allvue's security standard is a requirement source, the requirements it yields are pinned as constraints, the fleet builds against them and tests prove them. It is not yet a platform switch that stamps a security baseline into every generated service without a requirement saying so. Partial The gap and the proposal are at the end of the page.
The layers
| Layer | Allvue supplies | Cortex supplies | Standing |
|---|---|---|---|
| Identity provider | The OIDC / OAuth 2.0 provider (issuer, clients, scopes, MFA policy). | Platform sign-in federated to an OIDC issuer (authorisation-code flow, issuer discovery, JWKS, nonce, verified e-mail, optional pinning of the workspace domain). Today the federated issuer is Google Workspace; the flow is standard OIDC and the issuer is an operator setting. Password sign-in stays for break-glass. | Partial Generalising the issuer to Allvue's provider is configuration work on the platform side. |
| Session tokens | Nothing, for platform sessions. | An accounts service that alone can mint a session: RS256 access tokens signed with an RSA-2048 key held only by that service, public keys at a JWKS endpoint, refresh tokens that rotate with a short replay grace, revocation that logs a person out everywhere, key rotation as an operation. Every other service verifies with the public key and none can mint. | Available |
| Authentication of a generated application's users | Allvue's provider. | The app service authenticates against whatever its requirements name. The first production app service is an OIDC provider (Duende IdentityServer on .NET 8), which shows the runtime is not constrained; for Allvue the requirement is the other way round: the application is a relying party of Allvue's provider. | Partial A build pattern, proven per project; not a scaffold default yet. |
| Service-to-service authentication | Service identity in the VPC (managed identity, mTLS, a mesh) for delivered services. | Inside the platform every hop is authenticated: the API to the engine with an internal secret and a per-project signed grant that expires in five minutes; the API to the assistant with a purpose-bound short-lived JWT; the API to the accounts service with an internal secret. Between delivered services the platform supplies the connection configuration (service names rewritten per target, secrets from environment) and adds no protocol of its own. | Available on the platform; Allvue's mechanism between delivered services. |
| RBAC and ABAC | Roles and entitlements, and the API that answers them. | Platform roles (platform administrator, organisation administrator, member, application user) decided by one shared access rule that fails closed. Data access policies as versioned recipe rows: row filters over the data's columns with placeholders for the caller's attributes, and column masks lifted by an attribute. Attributes come from the membership or from an external attribute provider: Allvue's entitlement or RBAC API, called with the caller's e-mail and Allvue's headers, read at a chosen path, cached for a configurable time, and failing closed. | Available |
| Tenant authorization | The tenant attribute per user. | Tenant isolation is one row filter over the tenant column bound to that attribute, applied to every screen and every agent that reads the governed data. See Multi-tenancy. | Available |
| Token and secret management | The vault or key management service of the VPC for delivered services. | Per-project secrets minted by the platform, pushed into the fork's environment as secure values (never printed), rotated as an operation. Secrets live in environment settings, never in generated code, a specification or a test; a test reads a credential from the target's environment by key. A customer archive mints every credential per archive, scrubs platform passwords and is scanned for the shapes of known keys before handover. | Available |
| An agent acting on behalf of a user | The policy for delegated access. | Inside the platform an agent acts as the person: a chat agent commits as them; a delegate's tools are pinned by a server-side handle under the caller's bearer; a fleet job carries an on-behalf-of token that can only narrow the person's access; a workflow step completes under the identity the engine stamps. When an agent's tool calls an Allvue system, the endpoint forwards the call under a credential Allvue issues for the integration, carrying the verified caller identity and signed attributes; Allvue's layers enforce their rules on that identity. | Partial The end user's own IdP token is not exchanged and forwarded. |
| Tenant and container boundaries | The VPC, network policy. | A project is the unit of tenancy: its own configuration database, engine fork, target database, object-storage prefix and containers. App services run as their own deployments with the project's environment only; platform configuration and secrets are never mounted. Pods run as non-root with read-only root filesystems. | Available |
| Central policies inherited by every generated service | The security standard as a document. | Two inheritance mechanisms exist: engine endpoints on a shared core are inherited by every fork, and the fleet's scaffold fixes the shape of every new app service. What is not yet a mechanism is a security baseline applied to every generated service without a requirement stating it. | Partial See the proposal. |
| Audit trail and logging | Central log collection in the VPC for delivered services. | Every configuration change is a commit authored by the acting person's e-mail; every pipeline run records the commit it ran against; an audit log and a timeline per project; guarded agent answers go to a ledger with verdict, checks and tool calls; workflow definitions keep an append-only version history; a SOC 2 module runs control checks per project. | Available |
What cortex generates versus what Allvue infrastructure supplies
| Concern | Generated by cortex | Supplied by Allvue |
|---|---|---|
| The application's sign-in | Relying-party code against the provider the requirements name, with the redirect, token validation and session handling the standard prescribes | The provider, the client registration, scopes, MFA |
| The application's authorization checks | Whatever the requirements say, as code and as tests | The roles and entitlements, and the API that answers them |
| Access to governed project data | Row filters and column masks compiled per call from the caller's verified attributes | The attribute source (membership, or Allvue's entitlement API) |
| Secrets in the delivery | Blank keys with descriptions; per-archive credentials where the archive needs its own | The values, from Allvue's vault, at deploy time |
| Service identity between delivered services | Service names and connection configuration per target | The identity mechanism of the VPC |
| Audit of the build | Every change attributed and versioned; evidence on every task | Consumption of the audit trail |
| Audit of the running application | The application's own logs, health endpoints, the runbook's monitoring section | Log collection and retention |
The mechanism, end to end
- A person or a client authenticates. A browser session carries an RS256 token from the accounts service; an MCP client carries an OAuth 2.1 bearer or a labelled access token; an application user admitted by a share link carries the same kind of session with a narrower reach.
- Every request re-derives access. The shared access rule checks the person's membership of the project and their role; an unknown project, a lapsed membership or a store error denies.
- The data call attaches a grant. For every call from an application to a project endpoint, the API compiles the active row and column policies against the caller's attributes into a short-lived grant (project, expiry, compiled filter, mask, the verified subject) signed with a per-project secret the fork also holds. The engine verifies the signature; an unsigned or invalid grant means strict fail-closed compilation.
- The endpoint runs with the identity in its input. The caller's claims are merged over the input, so an endpoint can trust them and an application can never forward its own identity fields through this call. An endpoint that calls an Allvue system carries the integration credential from the project's environment and passes on the verified identity and attributes.
- Everything is written down. The change is a commit under the person's e-mail; an agent's answer, if guarded, is a ledger row with its tool calls; a workflow step records who completed it.
What is not in place, and what we propose
| Gap | Today | Proposal |
|---|---|---|
| Platform sign-in federated to Allvue's own OIDC provider | Partial Standard OIDC code flow against one configured issuer (Google Workspace). | Make the issuer an operator setting per installation (issuer URL, client id and secret, allowed domain). Small platform change; Allvue's provider is then the login for Allvue's people on the platform. |
| Token exchange: the end user's IdP token forwarded to an Allvue gateway | Not built Endpoints act under an integration credential plus the verified identity and signed attributes. | Add a token-exchange step (RFC 8693 against Allvue's provider) to the data call, so an endpoint that reaches an Allvue gateway can present the user's own token where the gateway requires it. This is the item we would design with Allvue's architects, because the exchange policy is theirs. |
| A security baseline stamped into every generated service | Partial The scaffold fixes the shape; inheritance exists for engine endpoints; conformance is achieved per requirement. | An Allvue security profile as a requirement-source template every Allvue project starts from (relying party of Allvue's provider, no local user store, the entitlement API as the attribute provider, secrets from environment only, the logging shape) plus a matching scaffold variant and a test pack that fails a build when the profile is not met. Then the sentence "Allvue defines the security architecture once; cortex generates against it every time" is a mechanism, not a promise. |
| MCP bearers with expiry and scopes | Partial Bearers do not expire and carry no scopes; they are minted only by a signed-in person, carry exactly that person's access, are looked up on every request and revoked at once by deletion. | Expiring tokens with refresh and per-tool scopes chosen when a token is minted. Already planned on the platform. |
| Service identity between delivered services | Allvue's mechanism. | No change: the delivery carries names and configuration; the VPC supplies identity. |