Deployment and Security¶

Target architecture — not the current operating contract

The AWS reference described here is not packaged in the current release. Use Source deployment for implemented behavior.

Mission Control's first reference architecture is a single-tenant deployment inside one customer's AWS account and private network boundary. The reference establishes a secure, operable baseline while preserving portable product interfaces.

Reference deployment¶

One customer owns each deployment and its control, execution, telemetry, evidence, and Retrieval data.
Management and Control Kernel capabilities may begin as a modular service boundary; gateways, agent workers, Workflow workers, and indexing workers remain independently deployable.
Customer networking controls private service access, model-provider egress, MCP server reachability, administrative ingress, and telemetry destinations.
Modules are independently configurable but appear as one permissioned Mission Control product.
Customer CI/CD can deploy external Agents and set standard observed runtime version metadata. A future verified release-attestation contract requires a separate approved design.

Equal operational support for Azure, GCP, SaaS-hosted, and on-premise deployments is deferred until the AWS reference is stable. This is a sequencing decision, not a change to product semantics.

Identity and access¶

Customer SSO is the authority for human identity. Group-to-role mapping supplies the Developer, Administrator, Operator, Policy Owner, Auditor, and customer-defined access profiles. Mission Control applies environment scope, resource grants, contextual policy, and separation of duties after authentication.

The target uses short-lived workload credentials for Agents, gateways, workers, application services, and external runtimes. Current external code uses expiring ordinary user or service-account virtual keys bound to one Team and a key policy; a future workload-identity design must preserve that authority boundary without treating observed version metadata as proof.

Sensitive configuration, promotion, policy publication, approval, evidence export, and retention changes can require separate actors. Administrative and execution decisions are fully attributed.

Secrets and credentials¶

Provider, MCP server, signing, and service credentials remain in the customer secret manager. Mission Control stores versioned references and access metadata, then brokers narrowly scoped access to the gateway or service that needs it.

Secrets are never placed in resource definitions, browser clients, traces, prompts, Connector arguments, Evidence Events, or exports. Rotation updates the reference or resolved secret version without changing the durable identity of the provider, server, Connector, or deployment.

Networking and egress¶

Model providers are reachable only from the Model Gateway through approved egress paths.
MCP servers are reachable only from the Connector Gateway through approved private or controlled network paths.
Browsers and Embed SDK clients call authenticated application services, never providers, gateways, or MCP servers directly.
Internal service-to-service calls authenticate workloads, authorize environment scope, and propagate Run and Trace context.
Egress policy records the provider or server destination, environment, data class, purpose, and approved control profile.

The absence of an approved path fails closed for Action Connectors and cannot create a direct-call fallback for any governed execution.

Data protection and privacy¶

Data is encrypted in transit and at rest with customer-compatible key controls.
Control, execution, telemetry, evidence, and Retrieval data remain inside the customer boundary unless an approved provider or MCP call requires egress.
Environment isolation and least privilege apply to data access, operational tools, exports, and administrative interfaces.
Metadata-first capture is the default; prompt, response, tool, document, and business content requires an approved purpose.
Captured content has explicit redaction, access, retention, deletion, export, and legal-hold controls.
The customer secret manager remains the credential authority and enterprise source systems remain authoritative for their business data.

The resource and evidence model defines the logical data stores and content-capture contract.

Security controls¶

The reference baseline includes:

Customer SSO, group-to-role mapping, session controls, and strong authentication inherited from customer policy.
Short-lived, environment-scoped workload identity for services and agents.
Least-privilege capability grants plus contextual policy enforcement.
Private deployment, controlled ingress, and destination-restricted provider and MCP egress.
Customer-managed secret references and rotation support.
Encryption in transit and at rest.
Separation of duties for sensitive administration, promotion, policy, approval, and export operations.
Complete attribution for configuration changes, lifecycle transitions, access decisions, executions, corrections, and exports.
Health, incident, backup, recovery, evidence-outbox, and degraded-service behavior aligned with reliability and failure semantics.

Portability contracts¶

Portability is contractual rather than a promise of equal day-one infrastructure support:

Interface	Portability purpose
OpenAI-compatible Model Gateway	Keeps agent and Workflow clients independent of model-provider APIs
MCP Connector boundary	Keeps enterprise capability discovery and invocation independent of proprietary integration protocols
OpenTelemetry	Preserves interoperable Trace, metric, and log emission
Versioned external policy evaluation	Keeps effective policy testable and independent of module application code
Managed resource and SDK contracts	Supports future native/Agent Builder authoring without making observed external metadata authoritative
Shared event envelope and customer-owned evidence export	Preserves operating history and audit portability
Workload identity and future managed-release contracts	Allows runtimes to join the same governed estate without trusting caller-observed version fields

Moving to another environment may change infrastructure primitives, but it must not change resource identity, lifecycle, gateway enforcement, policy outcomes, Connector classification, evidence semantics, or role behavior.

Current governance mapping¶

The current source release uses Organizations, Teams, real user/service-account virtual keys and separate human management roles. Agent is managed application content; deployments own secretless execution access and publisher funding. Observe uses Requests, Traces, Sessions and Usage with separate metadata/content/export permissions. Historical identity terms in this target proposal are not the operating contract. See Current release.