Skip to content

Security

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.