Skip to content

Security by plane

Target

This page describes intended behaviour or structure. No implementation is claimed unless a section is explicitly marked Current implementation or Evidence.

Merged page (2026-10-09)

Nine per-platform security.md pages are consolidated here, one tab each, under the plane that now owns the content. The Trust & Operations plane owns the rules (policy, approval policy, secrets, audit, classification); each plane enforces them at its boundary. Everything below is Target. Verified facts that constrain it: identity and tenancy follow the canonical ADR-0100/0101 (ADR-0015); no PolicyEngineService, secret broker or audit aggregate exists; in the agent host the MCP endpoint is mapped without authorization by default; AI-specific threats (prompt and tool injection, cross-tenant retrieval, malicious MCP servers and skills, poisoned knowledge, unsafe generated commands) are listed in the plane index.

Consolidated from platforms/factory-studio/security.md (2026 target design). Technology names inside are profile statements, not requirements.

Target Architecture — Final-State Design

This page describes the final-state security model for the Factory Studio. Authentication via OpenIddict (ConnectSoft.AuthorizationServerTemplate) and the multi-tenant SignalR substrate are implemented today; the role model and per-module authorization below are the designed end state.

The Factory Studio is the human control surface of an autonomous factory, so its security posture is defence-in-depth at the edge: every page, BFF query, command, and real-time stream is authenticated, authorized, tenant-scoped, and audited. The Studio holds no factory secrets and owns no source-of-truth data, but because it is where human authority is exercised (approvals, overrides, installs), its authorization and audit guarantees are first-class.

Authentication

Authentication is provided by OpenIddict via ConnectSoft.AuthorizationServerTemplate, the same authorization server the rest of the factory uses.

  • OIDC / OAuth 2.1 code flow with PKCE. The Blazor shell authenticates users against the OpenIddict server using the authorization-code flow with PKCE; no credentials ever touch the BFF tier.
  • Bearer access tokens. The shell calls StudioBff and the realtime gateway with short-lived JWT access tokens; refresh tokens are rotated. Tokens carry tenantId, sub (userId), roles, and scopes.
  • Token validation everywhere. Every ConnectSoft.Factory.Studio.* service validates the token (issuer, audience, signature, expiry) on every request; the realtime gateway validates the token on SignalR connect and re-validates on group join.
  • Service-to-service auth. BFF-to-platform calls use the client-credentials flow (or on-behalf-of where user context must flow) so downstream platforms enforce their own authorization rather than trusting the BFF blindly.
  • Session continuity. The shell maintains the authenticated session context shared across all microfrontends; sign-out revokes the session and disconnects SignalR.

Authorization (RBAC)

Authorization is role-based, tenant-scoped, and enforced at the BFF, never only in the UI. UI hiding is a convenience; the authoritative check happens server-side on every query and command. Each of the 13 UI modules maps to read and act permissions per role.

Module authorization matrix

Legend: R = read/view, A = act (commands such as decide, override, install, edit).

Module Operator Architect Reviewer Approver QA Security Officer SRE FinOps Knowledge Steward Tenant Admin Platform Admin Viewer
Project Command Center R R R R R R R R R R R R
Blueprint Designer R R/A R R R R – – R R/A R/A R
Agent Flow Explorer R/A R/A R R R R R – R R/A R/A R
Artifact Lineage Browser R R R R R R – – R R R R
Knowledge Graph Explorer R R R R – R – – R/A R R R
Human Review Center R R/A R/A R/A R R – – – R/A R/A –
QA Center R R R R R/A R – – – R R/A R
Security Center R R R R R R/A R – – R R/A –
DevOps Center R/A R R R R R R/A – – R R/A R
Runtime Center R/A R – – R R R/A R – R R/A R
Cost Center R R – – – – R R/A – R/A R/A R
Marketplace Install Center R R/A – – – R – R – R/A R/A –
Admin / Settings – – – – – R – – – R/A R/A –
  • Least privilege. Roles grant only what a function needs; Viewer is read-only across most modules and excluded from review, security, and admin surfaces.
  • Override is privileged. AgentDecisionOverridden requires Approver or Platform Administrator and an explicit elevated scope, and is always audited (see Workflows).
  • Project-scoped grants. Roles are assignable per project as well as per tenant, so a Reviewer on one project is not automatically a Reviewer on another.
  • Policy checks. Sensitive commands additionally consult Governance, Security & Compliance policy evaluation before execution. This builds on the implemented Security & Access Control module.

Tenant isolation

  • tenantId is resolved from the access token (never from URL or body) and stamped on every downstream call, store query, Redis cache key, and SignalR group.
  • BFF read models, dashboard caches, and preview sessions are partitioned by tenantId; a tenant can never read or be pushed another tenant's data.
  • The realtime gateway authorizes group membership against the token's tenantId on connect and join, so the live stream is isolated exactly like REST.
  • Platform Administrator (ConnectSoft staff) is the only role that can operate cross-tenant, and every cross-tenant access is explicitly audited with elevated scrutiny.

Secret handling

  • The Studio holds no business secrets at rest and stores no artifact bodies; previews are rendered through expiring sessions over Knowledge artifact memory.
  • Service credentials, signing keys, and downstream client secrets are stored in Azure Key Vault and injected at runtime; nothing is committed to source or baked into MFE bundles.
  • Browser-delivered MFE bundles contain no secrets and no privileged endpoints — all privileged operations are server-side BFF commands.
  • Tokens are short-lived with rotating refresh tokens; SignalR connections re-authorize on reconnect.
  • Preview sessions never expose raw storage URIs (e.g. Blob SAS) to the client; the service proxies and redacts.

Audit

  • Every state-changing action — review decisions, overrides, escalations, saved-view sharing, marketplace installs, admin changes — emits a canonical-envelope event carrying tenantId, userId (as actor), traceId, and correlationId.
  • ReviewDecision is append-only and immutable, and is mirrored to the Governance audit sink, making the human-in-the-loop fully reconstructable.
  • Read access to sensitive surfaces (Security Center findings, restricted artifact previews, knowledge-graph restricted nodes) is logged for access auditing.
  • Audit records are correlated end to end with the originating factory lifecycle via traceId, supporting traceability and incident forensics.

Threat model

flowchart TB
    subgraph Threats["Threats"]
        T1["Cross-tenant data access"]
        T2["Privilege escalation / unauthorized override"]
        T3["Token theft / replay"]
        T4["Unauthorized real-time stream access"]
        T5["Sensitive artifact / secret exposure"]
        T6["Review tampering / repudiation"]
    end
    subgraph Mitigations["Mitigations"]
        M1["tenantId from token on every query, cache key, group"]
        M2["Server-side RBAC + Governance policy on every command"]
        M3["Short-lived JWT, PKCE, refresh rotation, Key Vault"]
        M4["SignalR group authorization on connect + join"]
        M5["Expiring preview sessions, redaction, no storage URIs"]
        M6["Append-only immutable decisions + envelope audit"]
    end
    T1 --> M1
    T2 --> M2
    T3 --> M3
    T4 --> M4
    T5 --> M5
    T6 --> M6
Hold "Alt" / "Option" to enable pan & zoom
Threat Mitigation
Cross-tenant data access Token-derived tenantId enforced on every BFF query, cache key, and SignalR group; isolation tests in CI.
Privilege escalation / unauthorized override Server-side RBAC + Governance policy evaluation on every command; override requires elevated role and audited rationale.
Token theft / replay Short-lived tokens, PKCE, refresh-token rotation, audience/issuer validation, secrets in Key Vault.
Unauthorized real-time access SignalR authorization on connect and group join; events filtered to authorized groups only.
Sensitive artifact / secret exposure Expiring, classification-checked preview sessions with server-side redaction; no secrets in MFE bundles.
Review tampering / repudiation Append-only immutable ReviewDecision; every action emits an audited envelope event mirrored to Governance.

Consolidated from planes/agent-runtime/security.md (2026 target design). Technology names inside are profile statements, not requirements.

Target

This page describes intended behaviour or structure. No implementation is claimed unless a section is explicitly marked Current implementation or Evidence.

Reviewed 2026-10-09

Target; in the agent host the MCP endpoint is mapped without authorization by default and anonymous callers are governed under a fixed identity. Permission scopes are declared at publication and enforced by the tool executor, model gateway and retrieval boundary. Consolidated in Trust & Operations security-by-plane.

Target Architecture — Final-State Design

Because the Agent Mesh runs autonomous agents that read knowledge, call models, invoke tools, and produce code, it is a high-value security surface. Its model is least-privilege, tenant-isolated, fully audited, and policy-enforced — every agent acts only within an explicit permission scope, every model call obeys a tenant model policy, and every action is an auditable event. The mesh defers cross-cutting policy to the Governance, Security & Compliance Platform.

Authentication

  • Workload identity — every mesh service and every caller authenticates with an Azure AD / Entra managed identity; there are no shared static credentials between services.
  • Service-to-service — internal calls (runtime → registry, runtime → router) use mutual workload identity over the internal network; internal endpoints are not exposed through the public gateway.
  • External callers — Control Plane, Factory Studio, and operators reach public endpoints through the factory API gateway with token-based authentication.
  • Provider auth — model provider credentials (Azure OpenAI / OpenAI / Ollama) are held by the Integration Platform, never by individual agents.

Authorization

Authorization is layered and re-evaluated on every operation — registration never grants standing access.

Layer Enforced where Checks
Tenant scope All services tenantId claim matches resource tenant.
Operation scope API + handlers Caller role (registrar, orchestrator, runtime, operator) permits the action.
Agent permission scope ToolAdapterService, ModelRouterService, Knowledge The acting AgentVersion's scope permits the tool, model policy, and classification.
Model policy ModelRouterService Provider/model selection complies with the task modelPolicyId and tenant routing.

Agent permission scoping

Every AgentVersion carries a least-privilege PermissionScope (tools, model policy, knowledge classification ceiling, resource actions). The mesh re-checks scope at each tool and model invocation, so a compromised or misbehaving agent cannot exceed its grant. Scopes are authorized by Governance at registration and audited on use. See Agent Registry.

Model policy enforcement

A modelPolicyId binds a task to allowed providers, models, regions, and cost ceilings. The ModelRouterService rejects any selection outside the policy, supports per-tenant model routing (e.g. a tenant restricted to in-region Azure OpenAI or to self-hosted Ollama for data-residency), and records the policy decision on every ModelInvocation.

Tenant Isolation

  • tenantId is part of every primary/secondary index used for tenant-scoped queries; cross-tenant reads are rejected at the handler.
  • Agent pools, context caches (Redis), and Blob payload containers are partitioned per tenant.
  • Events carry tenantId and broker subscriptions are tenant-filtered via the cs-tenant-id application property.
  • Context packages are access-checked per tenant by Knowledge governance before delivery.

Secret Handling

  • Secrets and provider credentials live in a managed secret store (Azure Key Vault), referenced by identity — never embedded in agent definitions, skills, prompts, or logs.
  • Configuration wiring is handled by the configuration/secret pipeline; the mesh resolves secret references at runtime via managed identity.
  • Prompt and response payloads are classified before storage; secrets detected in payloads are redacted (see threat considerations).

Audit

  • Every state transition and every model/tool invocation is an event in the canonical envelope, giving a complete, replayable audit trail keyed on traceId.
  • ModelInvocation and ToolInvocation records (with policy decisions) provide a per-call audit of what an agent did, with which model/tool, under which policy.
  • Audit events flow to the Observability & Feedback Platform and Governance for compliance reporting.

Threat Considerations

Threat Mitigation
Prompt injection via retrieved context or tool output Context is governed and classification-filtered by Knowledge; tool outputs are treated as untrusted and validated; skills bound prompt construction.
Prompt / output safety Inputs and outputs pass safety screening; validation includes policy rules; unsafe content fails validation and escalates.
Excessive agency (agent over-reaching) Least-privilege PermissionScope re-checked per call; bounded correction attempts; non-idempotent tools run once.
Data exfiltration Classification ceilings per agent; per-tenant model routing and data residency; redaction of sensitive payloads before storage.
Cost / token abuse Token budgets in context packages; cost ceilings in model policy; telemetry-driven anomaly detection.
Cross-tenant leakage tenantId guards on every store and subscription; partitioned caches and payload containers.
Poison / replay Idempotency on eventId; dead-letter quarantine via the PoisonTaskWorker with full envelope preservation.
Model provider compromise Provider credentials isolated in the Integration Platform; failover and policy-constrained provider selection.

Consolidated from platforms/integration-platform/security.md (2026 target design). Technology names inside are profile statements, not requirements.

Target Architecture — Final-State Design

This page describes the final-state security model of the Integration Platform. Because this platform is the factory's boundary to untrusted external systems, it carries the highest concentration of secret material and inbound attack surface — and is correspondingly the most tightly governed. Secrets live only in Azure Key Vault; nothing sensitive is ever persisted, logged, or placed in an event payload.

The Integration Platform sits at the edge, so its security posture defends two directions at once: outbound, it holds the credentials that let the factory act on external systems; inbound, it is the front door for webhooks from systems the factory does not control. Every control below ladders up to the factory pillars of governance, traceability, and multi-tenant isolation, and integrates with the Governance, Security & Compliance Platform.

Authentication

  • Service callers authenticate with OAuth2 client-credentials tokens issued by the factory identity provider; tokens carry tenantId and scope claims.
  • Factory Studio users authenticate with OAuth2 authorization-code + PKCE; the backend-for-frontend exchanges and never exposes tokens to the browser.
  • Vendor-facing auth uses ConnectSoft.Extensions.Http.OAuth2 to manage client-credentials and authorization-code token lifecycles for external APIs, refreshing transparently.
  • Workload identity — services authenticate to Key Vault and Azure resources via Managed Identity, eliminating bootstrap secrets.

Authorization

  • Scope- and role-based authorization on every endpoint. Representative scopes: integration.connections.write/read, integration.providers.write, webhooks.subscriptions.write, webhooks.deliveries.ingest, integration.runs.read, integration.credentials.rotate.
  • Least privilege per service. Each integration service is granted only the Key Vault entries and provider scopes it needs; the VendorApiClientRegistryService alone holds credential-rotation rights.
  • Sensitive actions are gated. Establishing connections, rotating credentials, and replaying deliveries require elevated scopes and emit audited events.

Tenant Isolation

  • tenantId is a mandatory claim and predicate on every store access, Key Vault namespace, and Blob container.
  • No query path spans tenants; provider/API-client catalogue rows may be global (read-only) but connections, credentials, and deliveries are always tenant-owned.
  • Rate-limit buckets and circuit-breaker state are partitioned by tenant so one tenant cannot exhaust another's vendor budget.

Secret Handling

This is the platform's defining control.

  • Key Vault is the only secret store. All API keys, OAuth2 client secrets, signing secrets, and tokens live in Azure Key Vault. Aggregates store only keyVaultRef plus a non-reversible SecretFingerprint.
  • Plaintext-free guarantee. Secrets are resolved transiently at call time, used in-memory, and never written to a database, log line, trace attribute, or event payload.
  • OAuth2 lifecycle. ConnectSoft.Extensions.Http.OAuth2 acquires, caches in-memory, and refreshes vendor tokens; refresh tokens are stored only as Key Vault references.
  • Rotation by default. The CredentialRotationWorker rotates secrets on policy or demand, keeping the prior version active until the new one passes a verification run (see Workflows).
  • Soft-delete + purge protection on Key Vault; rotation retains prior versions for rollback.

Webhook Security (Inbound)

  • Signature verification. Every inbound delivery is verified against the provider's signature scheme (HMAC-SHA256 / JWS) using a per-subscription signing secret from Key Vault before any processing.
  • Tenant resolution. The owning tenantId is resolved from the verified subscription, never from untrusted payload fields.
  • Replay protection. Deliveries are idempotent on providerDeliveryId; timestamps and nonces guard against replay.
  • SSRF defense (outbound). Subscription endpoints must be HTTPS and pass an allow-list / private-IP-block check before any delivery; raw payloads are size-capped.

Audit

  • Every connection lifecycle change, credential rotation, webhook subscription, and delivery replay emits a canonical event carrying operator identity and traceId.
  • CredentialRotated, WebhookSubscribed, and IntegrationFailed (auth) flow to the Governance, Security & Compliance Platform for the immutable audit trail.
  • Access to credential metadata and payload bodies is logged with subject, action, and resource.

Threats & Mitigations

Threat Mitigation
Credential leakage Key Vault-only storage; plaintext-free guarantee; fingerprints in logs
Stolen/long-lived secrets Automated rotation; short-lived OAuth2 tokens; Managed Identity
Forged inbound webhooks Mandatory signature verification + per-subscription secret + replay protection
SSRF via outbound endpoints HTTPS-only + allow-list + private-IP block on subscription endpoints
Cross-tenant access tenantId predicate on every store/secret/blob access; partitioned buckets
Vendor abuse / runaway cost Per-tenant rate limits, circuit breakers, and quota enforcement
Poison/malicious payloads Size caps, schema validation, dead-letter isolation with preserved envelope
Privilege escalation Least-privilege scopes; rotation rights confined to the registry service

Credential Governance

Credentials are governed as first-class assets, not configuration:

  • Ownership & classification. Each IntegrationCredential has a tenant owner and sensitivity classification applied by Governance.
  • Lifecycle policy. Rotation cadence, expiry, and revocation rules are policy-driven and enforced by the CredentialRotationWorker.
  • Revocation. Compromised credentials are revoked centrally; dependent connections move to Degraded and stop executing runs until re-credentialed.
  • Separation of duties. The service that uses a credential is distinct from the registry service that custodies and rotates it.

Consolidated from platforms/marketplace/security.md (2026 target design). Technology names inside are profile statements, not requirements.

Target Architecture — Final-State Design

This page describes the final-state security model of the Marketplace Platform. It builds on the factory authorization server, ConnectSoft.Extensions.WebSecurity, and the Governance, Security & Compliance platform. Because the Marketplace distributes installable code into tenants, publisher trust and asset signing are first-class controls.

The Marketplace is a supply chain for installable assets, so its threat surface is the supply chain itself: who may publish, what gets distributed, who may install, and how integrity is guaranteed end to end. Security is enforced at the edge (authn/authz), in the domain (invariants), at the data layer (tenant isolation), and across the lifecycle (signing, scanning, audit).

Authentication

  • OAuth2 / OpenID Connect — every API and UI call carries a bearer token issued by the factory authorization server (AuthorizationServerTemplate). Tokens carry tenantId, subject, scopes, and (for publishers) publisherId.
  • Service identity — inter-service calls use workload identities with mutual TLS in the service mesh; internal APIs are not reachable from the public gateway.
  • Agent identity — Agent Mesh callers present a delegated token scoped to a task- id, so autonomous installs are attributable to a specific agent task.

Authorization

Authorization is scope-based plus tenant-scoped roles (see APIs):

Scope Grants Additional check
marketplace.read Browse, view detail, search Catalog visibility for tenant
marketplace.install Install assets Project access + valid License for paid assets
marketplace.publish Publish assets, release versions publisherId must be Verified and not suspended
marketplace.review Submit reviews Verified install of the asset
marketplace.admin Manage publishers, pricing, trust tiers Tenant admin role

Domain invariants enforce authorization-relevant rules independently of the edge (e.g. an unverified publisher cannot release a signed version, a withdrawn asset cannot be installed) — defense in depth.

Tenant isolation

  • Every store row, query, event, and cache key is tenantId-scoped; NHibernate global filters and handler-level tenant guards prevent cross-tenant access (see Data Model).
  • Shared/public assets are modeled under a platform tenant and exposed via catalog visibility rules, never by relaxing row filters.
  • Package storage uses per-tenant path prefixes/containers where required; signed package URLs are short-lived and tenant-scoped.

Secret handling

  • Azure Key Vault holds all secrets: publisher signing keys (referenced by SigningKeyRef, never stored in SQL), package store credentials, billing integration secrets, and service credentials.
  • Secrets are retrieved via managed identity at runtime; nothing secret is logged, returned by APIs, or shown in the UI.
  • Configuration follows the Options pattern; secret material is injected from Key Vault, not from app settings.

Publisher trust

  • Publishers have a verification status (Unverified → Pending → Verified → Suspended) and a trust tier (T0 community → T3 first-party ConnectSoft).
  • Trust tier governs publishing friction: low-tier publishers require manual policy approval and stricter quality gates; high-tier publishers may auto-approve within policy.
  • Reputation (from reviews, install success, and incident history) feeds trust-tier review; sustained quality failures or security incidents can suspend a publisher, blocking new installs of their assets.

Asset signing and integrity

  • Every released AssetPackage is signed with the publisher's Key Vault-backed key; AssetVersion.Signed and Signature record this.
  • Packages are content-hash addressed; ContentHash is verified on every read/install, so tampering is detectable.
  • Installation refuses unsigned or hash-mismatched packages; the installation flow validates signature and hash before Applying.
  • Quality scanning (AssetQualityScanWorker) runs security checks (secret/malware/vulnerability heuristics, policy compliance) before release.

Audit

  • Every state change emits a canonical event with tenantId, traceId, correlationId, and actor (requestedBy/publisherId), providing a complete, immutable audit trail.
  • Publishing, installation, license grant/revoke, and trust-tier changes are auditable end to end and ingested by Governance and the Knowledge Platform.
  • Provenance (AssetInstallation → version → package → publisher → license) answers "what was installed, from where, by whom, under what license" for any tenant.

Threat model

Threat Mitigation
Malicious or tampered package Signing + content-hash verification on read/install; quality/security scan gate before release
Unauthorized publishing Publisher verification + marketplace.publish scope + signed-version invariant
Cross-tenant data access Tenant-scoped filters, guards, and storage prefixes; defense-in-depth invariants
Privilege escalation via install Project-access check + license check + compatibility gate before apply
Secret leakage Key Vault-only secrets, managed identity, no secret logging/return
Dependency confusion / conflict Deterministic dependency resolution with conflict detection before install
Reputation gaming (fake reviews) Reviews gated on verified install; moderation and reputation scoring
Supply-chain replay/poisoning Immutable, versioned packages; idempotent sagas; dead-letter preservation for forensic replay

Continue to Observability, Workflows, and Governance, Security & Compliance.

Consolidated from platforms/devops-gitops/security.md (2026 target design). Technology names inside are profile statements, not requirements.

The DevOps / GitOps Platform holds the keys to the kingdom — it commits code, builds it, and ships it to production. Its security model is correspondingly strict: every action is authenticated, authorized, tenant-isolated, secret-safe, and audited.

Target Architecture — Final-State Design

The controls below align with the Governance, Security & Compliance Platform, which owns the policy engine and audit ledger this platform integrates with.

Authentication

  • All API and gRPC calls require an OAuth2 / OpenID Connect bearer token issued by the factory authorization server (ConnectSoft.AuthorizationServerTemplate).
  • Agents authenticate as workload identities (client-credentials) with short-lived tokens; humans authenticate interactively via Studio.
  • Service-to-service calls and worker message consumption use managed identities (Azure AD) — no static credentials in code or config.

Authorization

  • Coarse-grained OAuth scopes per bounded context: devops.repositories.write, devops.pipelines.run, devops.releases.plan, devops.releases.approve, devops.iac.provision, etc.
  • Fine-grained, attribute-based decisions (tenant, project, environment, module) are evaluated by the Governance policy engine before sensitive actions.
  • Segregation of duties — POST /releases/{releaseId}/approve requires an identity distinct from the release planner; production promotions can require a human approver.
  • Least privilege: each service holds only the scopes it needs; provisioning and approval are separate roles.

Tenant Isolation

  • Every request carries a tenant context (ConnectSoft.Extensions.Saas.AspNetCore); handlers assert tenantId against the operation scope before any store access.
  • NHibernate global filters enforce tenantId at the data layer so no query can cross tenants.
  • Blob containers, Azure Artifacts feeds, ACR repositories, and Git repositories are namespaced per tenant/project; cross-tenant access is structurally impossible.

Secret Handling

  • All secrets — Azure DevOps PATs/service connections, registry credentials, cloud provider credentials, signing keys — live in Azure Key Vault, referenced by managed identity at runtime. Nothing is stored in repositories or pipeline YAML.
  • Service connections in Azure DevOps are scoped per project and use workload-identity federation where possible, avoiding long-lived secrets.
  • Pulumi configuration secrets are encrypted in the Pulumi backend and resolved from Key Vault at apply time.
  • Pipeline variables marked secret are masked in logs; generated YAML never inlines a secret value.
  • Secret rotation is automated; rotated values propagate via Key Vault references without redeployment.

Supply-Chain Security

  • Container images are vulnerability-scanned in ACR; images failing the threshold cannot be promoted.
  • NuGet packages are restored only from approved Azure Artifacts feeds; published versions are immutable.
  • Commits and (where required) tags are signed; pipeline provenance (build → artifact → image) is recorded for SLSA-style attestation.
  • GitOps desired state is the only path to production; ad-hoc cluster changes are reverted by reconciliation.

Audit

  • Every state change emits an envelope-wrapped event with traceId, tenantId, and actor identity; the Governance Platform records release approvals, promotions, and provisioning in an immutable audit ledger.
  • Audit records are retained 7 years for releases/approvals (see Storage).
  • Human and agent actions are equally attributed and traceable.

Threat Model

Threat Mitigation
Unauthorized deployment to production Mandatory approval + policy gate; segregation of duties; GitOps-only path
Secret leakage in logs/YAML Key Vault references; secret masking; no inline secrets
Cross-tenant data access Tenant context assertions + NHibernate filters + namespaced stores
Compromised dependency / image Feed allowlists, immutable versions, image scanning, provenance attestation
Pipeline tampering Generated YAML from trusted templates; protected branches; signed commits
Drift / unauthorized cluster change Continuous GitOps reconciliation reverts out-of-band changes
Privilege escalation via agent Workload identities with least-privilege scopes; short-lived tokens

Pillar Alignment

  • Governance — policy-gated approvals and an immutable audit ledger.
  • Multi-tenant scale — isolation enforced at request, data, and storage layers.
  • Traceability — every security-relevant action is an attributed, traceable event.

Consolidated from platforms/runtime-cloud/security.md (2026 target design). Technology names inside are profile statements, not requirements.

Target Architecture — Final-State Design

Security in the Runtime & Cloud Platform is defense-in-depth: every call is authenticated and tenant-scoped, secrets never leave Azure Key Vault, and tenant isolation declared at generation time becomes enforced runtime isolation. Policy and audit integrate with the Governance, Security & Compliance Platform.

Authentication

  • Service callers (Control Plane, DevOps, Studio) authenticate with OAuth2 / OpenID Connect bearer tokens issued by the factory authorization server (OpenIddict).
  • Workload-to-Azure authentication uses managed identities (workload identity on AKS, system/user-assigned identities on Container Apps, Functions, and App Service) — no credentials in config or images.
  • Service-to-service calls inside the platform use mTLS within the cluster mesh plus token-based identity, and assert the canonical envelope tenantId/traceId.

Authorization

  • Coarse-grained access uses runtime.{resource}.{action} scopes (see APIs).
  • Fine-grained, context-aware decisions (e.g. "may this principal deploy to a prod environment for tenant X?") are delegated to the Governance policy engine; production-affecting mutations require an explicit policy decision and are recorded.
  • Authorization is always evaluated after the tenant guard: the principal's tenantId must match the target environment's RuntimeTenantBinding.

Tenant Runtime Isolation

Tenant isolation is the platform's defining security property. RuntimeTenantBinding translates the generation-time tenancy model into enforced runtime boundaries:

Layer Silo Pool Shared
Compute Dedicated environment / node pool Shared cluster, dedicated namespace Shared namespace
Network Dedicated VNet / subnet Network policy per tenant Shared with policy
Data Dedicated database Shared DB, partitioned + row filters Shared DB, row-level tenantId filter
Secrets Dedicated Key Vault Shared vault, per-tenant access policy Shared vault, scoped references
Quota Full environment capacity Allocated quota Allocated quota
  • tenantId is a mandatory predicate on every store access (ConnectSoft.Extensions.Saas.*).
  • Network policies and namespace boundaries are provisioned by Pulumi and reconciled by the DriftDetectionWorker — an unmanaged cross-tenant route is itself a drift finding.

Secret Handling

  • All secrets live in Azure Key Vault; SecretBinding stores references only (keyVaultRef, secretName, currentVersion).
  • Workloads resolve secrets at runtime via managed identity; secret values never appear in RuntimeConfiguration, Blob, logs, telemetry, or events.
  • The SecretRotationWorker rotates secrets on schedule, emitting SecretRotated; bindings refresh to the new version without downtime.
  • Key Vault access is least-privilege per environment and tenant; access is audited to Governance.

Audit

  • Every mutating operation (provision, deploy, rollback, config publish, secret bind/rotate, scale, drift remediation) emits an enveloped event with traceId, principal, and tenantId, persisted as an immutable audit record and forwarded to Governance.
  • Health, scaling, and drift signals are correlated to the same trace, giving an end-to-end, tamper-evident operational record.
  • Audit retention aligns with the data-model retention policy and compliance requirements.

Threat Model

Threat Mitigation
Cross-tenant data access RuntimeTenantBinding enforced on every read/write; isolation drift treated as a finding
Secret leakage Key Vault-only storage; managed identities; no secrets in config/logs/events
Unauthorized deployment to prod Governance policy decision + runtime.deployments.write scope + tenant guard
Supply-chain tampering (images) Images pulled only from trusted ACR; digests recorded in RuntimeDeployment; drift detection flags unexpected images
Configuration drift / unmanaged resources Continuous drift detection vs Git/Pulumi desired state; auto- or review-gated remediation
Privilege escalation via workload identity Least-privilege managed identities scoped per service and environment
Denial of service / noisy neighbour Per-tenant quotas in RuntimeTenantBinding; scaling bounds; namespace resource limits
Replay / poison messages Envelope eventId idempotency; dead-letter with preserved envelope

Consolidated from platforms/governance-security-compliance/security.md (2026 target design). Technology names inside are profile statements, not requirements.

Target Architecture — Final-State Design

This page describes the final-state security architecture of the Governance, Security & Compliance Platform. Because this platform is the factory's security and trust layer, it both implements defence in depth for itself and provides the controls (policy, audit, isolation, secrets, classification, risk) that secure every other platform. It builds on the Security-First Architecture core principle.

Implemented

The platform reuses production ConnectSoft assets: OpenIddict identity (ConnectSoft.AuthorizationServerTemplate / ConnectSoft.IdentityTemplate), multi-tenant SaaS isolation (ConnectSoft.Extensions.Saas.*), web security middleware (ConnectSoft.Extensions.WebSecurity), audit (ConnectSoft.Extensions.AuditNet), and compliance (ConnectSoft.Extensions.Compliance). These are real, in-repo libraries, not planned components.

Security Model at a Glance

flowchart TB
    Request["Inbound request / agent action"] --> Auth["Authentication (OpenIddict OAuth2/JWT)"]
    Auth --> Tenant["Tenant resolution & isolation guard"]
    Tenant --> RBAC["RBAC scope check"]
    RBAC --> ABAC["ABAC policy evaluation (PDP)"]
    ABAC --> Risk["Risk-adaptive gate"]
    Risk --> Decision{"Decision"}
    Decision -->|Allow| Proceed["Proceed"]
    Decision -->|Deny| Block["Block"]
    Decision -->|Gate| Approval["Human approval"]
    Proceed --> Audit["Immutable audit"]
    Block --> Audit
    Approval --> Audit
Hold "Alt" / "Option" to enable pan & zoom

Authentication

  • Protocol — OAuth2 / OpenID Connect with JWT bearer tokens, issued and validated by OpenIddict (ConnectSoft.AuthorizationServerTemplate). Humans authenticate interactively; services use the client-credentials flow.
  • Token validation — every service validates issuer, audience, signature, expiry, and the tenantId claim. Tokens are short-lived; refresh is handled at the Studio/BFF edge.
  • Service-to-service — inline PDP and gRPC supplier calls carry client-credentials tokens scoped to governance.*; mTLS is enforced inside the mesh as a second factor.
  • No ambient trust — there is no "internal network = trusted" assumption; every call is authenticated and authorized, including worker-to-service messaging (MassTransit messages carry the originating identity context).

Authorization

Authorization is two-layered, and the platform governs itself with the same policy engine it offers others.

RBAC (coarse)

Scope-based checks per endpoint and operation:

Scope Grants
governance.policy.read / .write View / author policy definitions and rules.
governance.policy.evaluate Call the inline PDP (POST /policies/evaluate).
governance.approval.decide Approve/reject requests (subject to ABAC + segregation of duties).
governance.audit.read Query the audit trail.
governance.compliance.generate Generate compliance reports.
governance.security.read / .write View / raise/triage security findings.

ABAC (fine)

The policy decision point evaluates attribute-based rules on every sensitive operation — subject attributes (role, agentId), resource attributes (type, DataClassification, environment), action, tenant, and RiskScore. This is the same PolicyEngineService described in Workflows; governance operations (e.g. publishing a policy, downgrading a classification) are themselves gated by ABAC and may require approval.

Segregation of duties

ApprovalService enforces that the subject who raised (or whose action triggered) an ApprovalRequest cannot be its approver, and that approval scopes are distinct from the requesting scopes.

Tenant Isolation

  • Enforced at every layer — tenantId is asserted from the token by ConnectSoft.Extensions.Saas.AspNetCore / ConnectSoft.Extensions.WebSecurity middleware, filtered at the NHibernate session by ConnectSoft.Extensions.Saas.NHibernate, and applied to Service Bus subscription rules so a tenant never sees another's events.
  • Isolation as governed policy — TenantIsolationRule makes cross-tenant access an explicit, auditable grant; the default is Strict (deny). Data residency is enforced per rule.
  • Per-tenant audit chains — AuditEntry hash chains are scoped per tenant, so integrity is independent across tenants.
  • High-isolation editions — can be mapped to database-per-tenant for audit/compliance stores and customer-managed encryption keys.

Secret Handling

  • References, never values — SecretGovernanceService stores only SecretReferences (vault URI, name, version, rotation policy). Secret material lives exclusively in Azure Key Vault and is read by the owning service via managed identity — the governance platform never reads or proxies values (see Storage).
  • Leak detection — SecretScanWorker scans artifacts, config, and commits; a detected leak raises a High/Critical SecurityFinding, marks the reference Compromised, and forces rotation.
  • Rotation policy — each reference has a rotation cadence; due/overdue references surface in the Security Center and emit reminders.
  • No secrets in config — connection strings and keys are resolved from Key Vault at runtime; nothing sensitive sits in app settings or pipeline variables in plaintext.

Audit

  • Immutable & tamper-evident — every governance-relevant action writes an append-only AuditEntry, hash-chained (hash = sha256(previousHash + canonical(entry))) per tenant, via ConnectSoft.Extensions.AuditNet.
  • Complete — decisions, approvals, findings, classifications, secret events, and policy changes are all audited; the trail is queryable by traceId for end-to-end provability.
  • Exported & retained — the AuditExportWorker streams entries to immutable (WORM) Blob storage for long-term, regulator-grade retention (see Data Model retention).
  • Self-auditing — reads of the audit trail are themselves audited.

Threat Model

Threat (STRIDE) Vector Mitigation
Spoofing Forged identity / token replay OpenIddict-validated short-lived JWTs, mTLS service-to-service, no ambient trust.
Tampering Altering decisions/audit Append-only stores; per-tenant hash-chained audit; immutable WORM exports; immutable published policy versions.
Repudiation Denying an approval/decision Attributable ApprovalDecision (approverId, justification); full audit chain by traceId.
Information disclosure Cross-tenant leakage; secret exposure Strict tenant isolation (token → session → topic); secret references only; classification-driven redaction in Knowledge Platform.
Denial of service Flooding the PDP / ingestion Rate limiting (ConnectSoft.Extensions.RateLimiting), worker prefetch/concurrency caps, autoscale, circuit breakers.
Elevation of privilege Bypassing gates; self-approval Default-deny; fail-safe on expiry; segregation of duties; ABAC on governance operations themselves.
Prompt injection / exfiltration (AI-specific) Malicious prompts/responses via agents Prompt-safety policy domain, risk scoring, memory-access policy, classification of artifacts.
Supply-chain / artifact Malicious or non-compliant generated artifacts Artifact policy domain, security findings ingestion, deployment gates.

Security Principles

  • Default-deny, fail-safe — absence of an explicit allow is a deny; timeouts block rather than open.
  • Defence in depth — authentication, RBAC, ABAC, tenant isolation, classification, secret governance, and risk gates compose.
  • Governance governs itself — the platform applies its own policy engine to its own sensitive operations.
  • Everything provable — every decision and approval is recorded, attributable, and replayable by traceId.
  • Least privilege & zero standing access — scopes are minimal; cross-tenant access is explicit and time-bound.

Consolidated from platforms/observability-feedback/security.md (2026 target design). Technology names inside are profile statements, not requirements.

Target Architecture — Final-State Design

This page describes the final-state security model of the Observability & Feedback Platform. Telemetry is sensitive — it can reveal tenant behaviour, cost, and defects — so the platform treats observability data as a protected, multi-tenant asset.

Observability data is a high-value, high-sensitivity asset: traces and logs can contain operational detail, cost data is commercially sensitive, and feedback reveals defects. The platform's security model protects this data with strong authentication, fine-grained authorization, hard tenant isolation, managed secrets, and complete audit.

Authentication

  • OpenIddict-issued tokens. All API and UI access is authenticated via OpenIddict bearer tokens issued by the ConnectSoft authorization server (ConnectSoft.AuthorizationServerTemplate / ConnectSoft.IdentityTemplate).
  • Service-to-service. Inter-service and worker calls use workload identities (managed identity on AKS/Container Apps) and validate tokens on every hop.
  • Telemetry ingestion. OTLP ingestion from runtime and agents is authenticated with per-environment ingestion keys / managed identity; spans are validated to carry a tenantId before acceptance.

Authorization

Authorization is enforced on three axes (see APIs — Authorization):

Axis Mechanism
Tenant scope Token tenantId claim must match the resource tenant; checked before any store access.
Scope claims observability.read, observability.write, observability.incidents.
Role mapping runtime.operator (Runtime Center), cost.analyst (Cost Center), quality.reviewer (QA Center).

Read access to logs and traces is the most tightly controlled because those payloads can contain sensitive operational data; cost data is restricted to cost.analyst and governance roles.

Tenant Isolation

  • tenantId everywhere. Every aggregate, series, log reference, dashboard, alert, incident, feedback item, and cost signal carries tenantId (see Data Model — Multi-Tenancy).
  • Query-time injection. LogQueryService and MetricAggregationService inject the caller's tenantId into every Log Analytics/metric query; a client cannot widen the scope.
  • Correlation isolation. TelemetryCorrelation enforces that all linked refs share one tenantId; a traceId never crosses tenants.
  • Store partitioning. Telemetry workspaces and relational tables are partitioned by tenant; archives in Blob are tenant-pathed.

Secret Handling

  • Azure Key Vault. All connection strings, ingestion keys, and signing material are stored in Key Vault and accessed via managed identity — never in config files or images.
  • No secrets in telemetry. Serilog and OTEL pipelines apply redaction enrichers; the platform scrubs known secret patterns and PII from logs and span attributes at ingestion.
  • Scoped ingestion keys. Telemetry ingestion keys are per-environment and rotamatable; compromise of one environment's key does not expose others.

Audit

  • Every access is audited. API reads of traces, logs, cost, and feedback emit an audit record (actor, tenant, resource, traceId, decision) to the audit log.
  • Incident lifecycle is append-only. Every incident transition and escalation step is recorded immutably for post-mortem and compliance.
  • Immutable events. Published events are immutable once on the bus, providing a tamper-evident trail correlated by traceId.
  • Governance feed. Audit and access decisions are available to the Governance, Security & Compliance platform.

Threat Model

Threat Mitigation
Cross-tenant data access tenantId claim enforcement + query-time injection + correlation isolation.
Sensitive data in logs/traces Redaction enrichers + PII scrubbing at ingestion; restricted read scopes.
Cost data leakage cost.analyst/governance-only access; tenant scoping.
Telemetry spoofing / injection Authenticated ingestion; tenantId validation; per-environment keys.
Alert/incident tampering OpenIddict auth + role gating + append-only incident log + audit.
Replay / poison events Idempotency on eventId; dead-letter with envelope preserved; signed envelopes.
Secret exposure Key Vault + managed identity; no secrets in images or telemetry.
Denial of service via telemetry flood Per-tenant ingestion quotas, sampling, and backpressure on workers.

Consolidated from platforms/generated-saas-platform/security.md (2026 target design). Technology names inside are profile statements, not requirements.

Target Architecture — Final-State Design

This page describes the security architecture generated into every SaaS Product. Authentication is provided by ConnectSoft.AuthorizationServerTemplate (OpenIddict); tenant isolation and SaaS security patterns come from the ConnectSoft.Extensions.Saas.* libraries. Security is generated by construction — not bolted on — so every product inherits the same hardened baseline.

Security in a generated product is defense in depth: authentication at the edge, authorization at every service, tenant isolation in every store and message, secrets only in Key Vault, and an immutable audit trail recording every sensitive action. Each control is generated from a shared, hardened template.

Authentication (OpenIddict)

  • Token issuance. The Authorization Server (ConnectSoft.AuthorizationServerTemplate, OpenIddict) issues OAuth2/OIDC tokens. Supported grants: authorization code + PKCE (interactive portals/mobile), client credentials (service-to-service), and refresh tokens.
  • Validation. The API Gateway validates signature, issuer, audience, and expiry on every request before routing; each service re-validates and extracts claims (sub, tenantId, scopes/permissions).
  • Federation. External identity providers (Entra ID, social, SAML) can be federated through OpenIddict for enterprise tenants.
  • Token contents. Tokens carry tenantId, user id, role/permission scopes, and edition entitlements, enabling stateless authorization downstream.

Authorization (RBAC + ABAC)

  • RBAC. Users hold Roles; roles grant Permissions (e.g. subscription.manage). Endpoint authorization checks the required permission scope from the token.
  • ABAC. Attribute-based checks refine RBAC with context: resource ownership, tenant match, edition entitlement, and data classification. Example: a user with report.read may only read reports within their own tenant and permitted categories.
  • Entitlement gating. Capabilities are additionally gated by the tenant's Edition entitlements, so authorization reflects both who you are and what your plan includes.
  • Policy enforcement. Authorization policies are generated consistently across services from the blueprint permission model.

Tenant isolation

  • Identity boundary. Every token carries tenantId; the gateway and each service reject requests whose route/resource tenant does not match the token's tenant (except platform-admin scopes on the Tenants resource).
  • Data boundary. The NHibernate global tenant filter injects tenantId predicates on every query (or routes to schema/database-per-tenant); handlers additionally assert the envelope tenantId. See data model.
  • Message boundary. Every event carries tenantId; consumers assert it before acting, and Service Bus subscriptions filter on cs-tenant-id.
  • Cache boundary. Redis keys are prefixed by tenantId; no cross-tenant cache reads are possible.

Secret handling

  • Key Vault only. Connection strings, signing keys, integration credentials, and webhook secrets live exclusively in Azure Key Vault.
  • References, not secrets. Aggregates (IntegrationConnection, WebhookSubscription, secret-typed ConfigurationSetting) store a SecretReference pointer — never the secret value.
  • Managed identity. Services authenticate to Key Vault and data stores via managed identities; no secrets in code, config files, or images.
  • Rotation. Secrets and signing keys rotate on a schedule; services re-read on rotation without redeploy.

Audit

  • Immutable trail. Every authentication, authorization decision, and sensitive mutation emits AuditEntryRecorded, persisted append-only and archived to immutable Blob (see aggregate roots).
  • Correlated. Each AuditEntry stores TraceId, so security events correlate with the full request and event chain.
  • Tamper-evident. Audit records are write-once; the archive container is WORM-configured.

Threat model & mitigations

Threat Mitigation
Cross-tenant data access Token tenantId enforcement + NHibernate global filter + handler assertion + tenant-prefixed cache
Token theft / replay Short-lived access tokens, refresh rotation, PKCE, audience/issuer validation
Privilege escalation Server-side RBAC/ABAC; system roles/permissions immutable; entitlement gating
Secret leakage Key Vault-only secrets, managed identity, SecretReference indirection, no secrets in images
Injection / malformed input Generated input validation, parameterized NHibernate queries, schema validation on report/config
Poison messages / replay abuse Idempotency on eventId, dead-letter quarantine, bounded retry
Webhook abuse / SSRF HTTPS-only callbacks, signed payloads, allowlist + egress controls
Denial of service Per-tenant gateway rate limiting, autoscaling, circuit breakers on integrations
Audit tampering Append-only store + immutable Blob archive

Implementation Notes

Security controls feed the factory's Governance, Security & Compliance platform: audit events and policy decisions from the running product are surfaced as compliance evidence, closing the governance loop from intent to runtime.

How security contributes to the pillars

  • Traceability — audit entries carry traceId; every authz decision is correlatable to the originating request.
  • Reusability — auth, isolation, and secret patterns are generated from shared hardened templates and libraries.
  • Autonomy — the security baseline is generated automatically; agents do not hand-write auth wiring.
  • Governance — RBAC/ABAC, immutable audit, and policy gating are first-class and feed factory compliance.
  • Observability — security metrics (auth failures, denials, rate-limit hits) are emitted and dashboarded.
  • Multi-tenant scale — tenant isolation is enforced at identity, data, message, and cache layers simultaneously.