Security and identity

The concern: not whether the platform can generate authentication code, but whether an enterprise can enforce authentication, authorization and identity architecture centrally and consistently, at a platform level. OpenID Connect, acting on behalf of a user, OAuth, container and tenant boundaries, and no team inventing its own security pattern. The enterprise defines the security architecture once; every generated service must conform to it.

The short answer

That is the shape the platform 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 the platform (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 the enterprise's own entitlement API, secrets are per project and never in code, and every change is an attributed commit. In place

For what runs as the application (an application service in the customer's network), the security architecture is the customer's, and the platform builds against it: the customer's identity provider, service identity and gateway. Today that conformance is achieved the way every other requirement is: the customer'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 next step are at the end of the page.

The layers

Layer	The enterprise supplies	The platform supplies	Standing
Identity provider	The OpenID Connect and OAuth 2.0 provider (issuer, clients, scopes, MFA policy).	Platform sign-in federated to an OpenID Connect issuer (authorisation-code flow, issuer discovery, signing keys, nonce, verified e-mail, optional pinning of the workspace domain). Today one workspace issuer is configured per installation; the flow is standard and the issuer is an operator setting. Password sign-in stays for break-glass access.	Partial Pointing the issuer at a customer's provider is configuration work.
Session tokens	Nothing, for platform sessions.	An accounts service that alone can mint a session: asymmetrically signed access tokens with a private key held only by that service, public keys at a standard key-set 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.	In place
Authentication of a generated application's users	The customer's provider.	The application service authenticates against whatever its requirements name. The first production application service is itself an OpenID Connect provider, which shows the runtime is not constrained; the more common requirement is the reverse: the application is a relying party of the customer's provider.	Partial A build pattern, proven per project; not a scaffold default yet.
Service-to-service authentication	Service identity in the network (managed identity, mutual TLS, 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 token; 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.	In place on the platform; the customer's mechanism between delivered services.
Roles and attributes	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 configuration 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: the enterprise's entitlement or role API, called with the caller's e-mail and the enterprise's headers, read at a chosen path, cached for a configurable time, and failing closed.	In place
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.	In place
Token and secret management	The vault or key management service of the network 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.	In place
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 enterprise system, the endpoint forwards the call under a credential the enterprise issues for the integration, carrying the verified caller identity and signed attributes; the enterprise's layers enforce their rules on that identity.	Partial The end user's own identity-provider token is not exchanged and forwarded.
Tenant and container boundaries	The network, network policy.	A project is the unit of tenancy: its own configuration database, engine fork, target database, object-storage prefix and containers. Application 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.	In place
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 application service. What is not yet a mechanism is a security baseline applied to every generated service without a requirement stating it.	Partial See below.
Audit trail and logging	Central log collection in the network 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 compliance module runs control checks per project.	In place

What the platform generates and what the enterprise supplies

Concern	Generated by the platform	Supplied by the enterprise
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 the enterprise's entitlement API
Secrets in the delivery	Blank keys with descriptions; per-archive credentials where the archive needs its own	The values, from the enterprise's vault, at deploy time
Service identity between delivered services	Service names and connection configuration per target	The identity mechanism of the network
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 a signed 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 enterprise 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.

Still to do

Gap	Today	Next step
Platform sign-in federated to a customer's own identity provider	Partial Standard OpenID Connect code flow against one configured workspace issuer.	Make the issuer an operator setting per installation (issuer URL, client id and secret, allowed domain). A small platform change; the customer's provider is then the login for the customer's people on the platform.
Token exchange: the end user's identity-provider token forwarded to a customer gateway	To do Endpoints act under an integration credential plus the verified identity and signed attributes.	Add a token-exchange step (the OAuth 2.0 token exchange standard, against the customer's provider) to the data call, so an endpoint that reaches a customer gateway can present the user's own token where the gateway requires it. The exchange policy is the customer's, so this is designed with their architects.
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 enterprise security profile as a requirement-source template every project of that enterprise starts from (relying party of the enterprise'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 "define the security architecture once; generate 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.
Service identity between delivered services	The customer's mechanism.	No change: the delivery carries names and configuration; the network supplies identity.