Technical security architecture for governed execution.

Where Operious stores channel credentials, the target design is AES-256-GCM encryption with per-tenant keys derived using HKDF. AES-256-GCM provides authenticated encryption, while HKDF supports deterministic derivation of tenant-scoped key material from approved secret inputs. The operational intent is simple: a credential for one tenant should not be usable from another tenant context.

Credential handling is part of enterprise review because key custody, rotation, residency, and cloud provider controls can vary by deployment. Operious treats those choices as security architecture, not implementation trivia.

Tenant isolation is enforced through data modeling and service boundaries. Records that belong to a tenant carry tenant context, and service access paths are expected to resolve tenant identity before reading or writing operational state. The database layer can enforce row-level isolation patterns so accidental cross-tenant access is not merely a UI concern.

This matters in a multi-agent system because agents may retrieve knowledge, inspect sessions, write events, and invoke channel adapters. Every one of those actions must carry tenant identity. A missing tenant context is a governance and security failure, not a harmless default.

The operational event fabric is designed as an append-only audit spine. Governance decisions, execution attempts, denials, approvals, supervisor findings, and projection updates are written as facts. Where deployment controls enable cryptographic chaining, events can carry tamper-evident relationships that strengthen forensic reconstruction.

The important architectural point is that auditability is not delegated to separate log files. Logs are useful for engineering operations. The event fabric is part of the product state and is used to reconstruct what the organization did.

Operious separates substrates so that cognition, governance, execution, supervision, and arbitration do not collapse into one informal code path. Static analysis and dependency audits are used to identify cross-substrate imports and bypass paths that would let execution avoid governance or tenant controls.

This discipline protects the system from the most common failure of fast-moving AI products: one convenient integration path that calls a tool directly because it was easier than routing through policy. In Operious, those paths are treated as architectural violations.

Execution code is designed to require governance admission before invoking external systems or mutating operational state. The admission record links subject, actor, capability, evidence, policy chain, and decision result. Without admission, execution should fail closed.

This gives security and compliance teams a direct review object. They can ask which actions require admission, how admission is issued, how denial is recorded, and how an event connects back to execution.

Security architecture becomes real only when it is mapped to a tenant's systems, data classes, integrations, cloud posture, and regulatory obligations. Operious architecture reviews cover channels, credentials, event retention, access roles, encryption posture, logging, data residency needs, and incident response expectations.

Operious treats architectural boundaries as testable constraints. Static checks can verify that code does not import across forbidden substrate paths, that governance runtime boundaries are not bypassed, and that tenant-aware services do not quietly call lower-level utilities without context. This is not a replacement for security review, but it reduces the chance that convenience erodes the design.

Dependency discipline also matters in regulated deployments. A smaller, clearer path between cognition, governance, execution, and audit makes it easier for security teams to review how data and authority move through the system.

Security architecture must describe failure, not only success. When tenant context is missing, execution should deny. When credential resolution fails, the action should stop. When governance cannot produce admission, the workflow should preserve the denial instead of retrying through an ungoverned path.

These failure records become part of the audit fabric. They help teams distinguish malicious behavior, misconfiguration, missing evidence, and ordinary operational uncertainty.

Security teams can then review not only whether controls exist, but how the system behaves when those controls block work.

That failure behavior is a core part of the security model, especially for systems that can coordinate actions across channels, tools, credentials, and records.