Authority & policy
Explicit delegated machine authority, deterministic policy and exact approvals/permits.
3 build-scoped objectivesSIO18 · TRUST / SECURITY / DEPLOYMENT
Trust should be inspectable before authority is granted.
StableMind governs consequential machine actions, so its security story cannot stop at a badge wall. This center exposes the engineering security model, deployment boundaries, credential-custody rules, build-scoped assurance doctrine, and the exact limits of what has been externally proven.
01 / SECURITY MODEL
Security is part of the authority chain.
For StableMind, security is not a perimeter around an otherwise autonomous agent. It is woven into how machine power is created and constrained. Identity proves who or what is acting. Delegated authority determines whether that principal may exercise a class of power. ActionGate evaluates an exact semantic action under deterministic policy. An Action Permit constrains the authorized action. Only then may Execution Fabric materialize the narrow, temporary technical capability required to execute it.
That ordering matters because a credential, token, API key, connector session, model identity, workflow role or successful authentication can provide capability without establishing permission. StableMind therefore keeps identity, authority, credentials, execution and evidence constitutionally separate. Security controls may narrow, suspend, quarantine or revoke execution eligibility; they never create authority just because the system is healthy.
02 / BUILD-SCOPED ASSURANCE
Controls need evidence. Evidence needs an expiry date.
The sealed security-assurance model contains 24 control objectives across 12 families. Every claim is designed to identify threats, controls, acceptance criteria, evidence, limitations, an owner and review cadence. A control that passed once is not treated as permanently effective, and a finding does not disappear because the release changed.
Credentials & signing
Just-in-time credential brokerage and signed release/package integrity.
2 build-scoped objectivesCustomer assurance
Customer-specific evidence collection, review boundaries and acceptance gates.
1 build-scoped objectiveTenant & data
Tenant/environment isolation plus provenance of instructions and context.
2 build-scoped objectivesDeployment
Explicit topology, locality, custody, upgrade, rollback and environment attestation.
2 build-scoped objectivesGovernance
Threat ownership, accountable security governance and residual-risk review.
2 build-scoped objectivesIdentity & access
Enterprise human/workload identity, separation of duties and strong authorization.
2 build-scoped objectivesIncident response
Findings, containment, revocation, recovery and attributable incident handling.
1 build-scoped objectiveEvidence & detection
Tamper-evident evidence, tenant-safe telemetry and attributable security detection.
3 build-scoped objectivesResilience
Availability semantics, recovery discipline and fail-closed behavior for consequential actions.
2 build-scoped objectivesSecure development
Build-scoped testing, source governance and engineering evidence.
2 build-scoped objectivesSupply chain
Package manifests, component provenance, signing and verifiable release lineage.
2 build-scoped objectivesAssurance attaches to exact artifacts.
An assurance package names the exact source, release manifest, deployment profile, tenant boundary and evidence set it evaluates. Passing evidence for one combination is not automatically transferable to a different build, topology, customer boundary or authority configuration.
Control effectiveness expires.
Evidence has freshness requirements and campaign results have validity windows. Stale evidence cannot become current simply because the underlying control description has not changed.
Exceptions and findings remain visible.
Exceptions are explicit, scoped, owned, approved, compensated and time limited. Findings retain severity, evidence, owner, due date, remediation, verification and final disposition instead of being erased from the story.
03 / CREDENTIAL CUSTODY
Managed does not mean credential custody.
StableMind’s deployment doctrine treats locality as part of the security model. Where control executes, where enforcement occurs, who owns keys, where credentials appear, where evidence is retained and how upgrades arrive are all explicit deployment facts. In managed and hybrid architectures, the doctrine keeps raw customer execution credentials inside the customer-controlled enforcement boundary rather than turning the StableMind control plane into a standing credential warehouse.
Just-in-time credential brokerage is downstream of an exact Action Permit. The credential is the technical capability to perform a permitted action, not proof that permission exists. Lease metadata and destruction evidence may become part of the attributable evidence chain; raw reusable secret material should not.
01Authority resolvedNo credential implication
02ActionGate decisionExact semantic request
03Action PermitBounded / short lived
04JIT capabilityCustomer enforcement boundary
05Execution receiptNo raw secret retained
06Independent evidenceProof remains separate
04 / DEPLOYMENT MODES
Run the authority boundary where your risk model requires it.
The source contains seven explicit deployment profiles. They range from local evaluation to customer-managed enterprise production architecture, private cloud, air-gapped enclaves, managed service and hybrid customer-local enforcement. The invariants do not move with topology: identity, tenant context, delegation, deterministic policy, exact permits, JIT credentials, enforcement, evidence, revocation, observability and availability semantics remain required.
NON_PRODUCTION
Developer Evaluation
A local, non-production profile for evaluating the authority chain without connecting consequential production systems.
- Control plane
- LOCAL HOST
- Enforcement
- LOCAL HOST
- Credentials
- LOCAL HOST
- Evidence
- LOCAL HOST
- Internet egress
- OPTIONAL
- Production-eligible config
- NO
CONTROLLED_INTERNAL
Single-Node Enterprise
A customer-managed controlled-internal profile that keeps control, enforcement, credentials, evidence and observability on a customer node.
- Control plane
- CUSTOMER NODE
- Enforcement
- CUSTOMER NODE
- Credentials
- CUSTOMER NODE
- Evidence
- CUSTOMER NODE
- Internet egress
- RESTRICTED
- Production-eligible config
- YES · ENGINEERING PROFILE
ENTERPRISE_PRODUCTION
Customer-Managed Kubernetes
A customer-managed high-availability profile with isolated credential and connector locality inside customer Kubernetes.
- Control plane
- CUSTOMER KUBERNETES
- Enforcement
- CUSTOMER KUBERNETES
- Credentials
- CUSTOMER KUBERNETES ISOLATED
- Evidence
- CUSTOMER STORAGE
- Internet egress
- RESTRICTED
- Production-eligible config
- YES · ENGINEERING PROFILE
ENTERPRISE_PRODUCTION
Private Cloud
A customer-owned private-cloud profile with customer identity, customer KMS/HSM, customer evidence storage and restricted egress.
- Control plane
- CUSTOMER PRIVATE CLOUD
- Enforcement
- CUSTOMER PRIVATE CLOUD
- Credentials
- CUSTOMER PRIVATE CLOUD ISOLATED
- Evidence
- CUSTOMER STORAGE
- Internet egress
- RESTRICTED
- Production-eligible config
- YES · ENGINEERING PROFILE
REGULATED_PRODUCTION
Air-Gapped Enclave
A regulated-production architecture profile with no internet egress and local/offline identity, policy, telemetry, evidence, time and signed-update paths.
- Control plane
- CUSTOMER ENCLAVE
- Enforcement
- CUSTOMER ENCLAVE
- Credentials
- CUSTOMER ENCLAVE ISOLATED
- Evidence
- CUSTOMER ENCLAVE
- Internet egress
- PROHIBITED
- Production-eligible config
- YES · ENGINEERING PROFILE
ENTERPRISE_PRODUCTION
StableMind Managed Service
A StableMind-managed control-plane profile whose execution boundary remains customer or dedicated-edge scoped; managed operation is not blanket credential custody.
- Control plane
- STABLEMIND MANAGED
- Enforcement
- CUSTOMER OR DEDICATED EDGE
- Credentials
- CUSTOMER OR DEDICATED EDGE
- Evidence
- CUSTOMER OR DEDICATED TENANT STORE
- Internet egress
- CONTROLLED
- Production-eligible config
- YES · ENGINEERING PROFILE
ENTERPRISE_PRODUCTION
Hybrid Customer-Local Enforcement
A managed-control-plane/customer-local-enforcement profile designed to keep execution credentials, connectors and evidence inside the customer-local boundary.
- Control plane
- STABLEMIND MANAGED
- Enforcement
- CUSTOMER LOCAL
- Credentials
- CUSTOMER LOCAL
- Evidence
- CUSTOMER LOCAL
- Internet egress
- OUTBOUND CONTROL CHANNEL ONLY
- Production-eligible config
- YES · ENGINEERING PROFILE
Production-eligible configuration ≠ production proof.
The underlying engineering profiles mark several topologies as production-eligible. SIO18 publishes that source fact, but it does not claim a customer is running them, that a regulator has accepted them, that customer HSM custody has been demonstrated, or that production failover, residency or isolation has been independently verified.
05 / AIR GAP & HYBRID
No hidden cloud dependency.
Air-gapped mode is not “mostly offline.” The doctrine requires local identity, policy, package, image, telemetry, evidence, time and update paths, with internet egress prohibited in the profile. Upgrades arrive as signed offline bundles rather than silently reaching across the boundary.
Hybrid enforcement follows the same principle from another angle. A managed control plane may help coordinate governance, but customer-local enforcement keeps the consequential execution path, credentials, connectors and evidence where the customer has chosen to place them. The point is not that one topology is universally safest. The point is that authority-relevant locality is explicit, reviewable and bound to the deployment profile.
CONTROLManaged or customer-owned
→ENFORCEMENTCustomer boundary
→CREDENTIALCustomer boundary
→EXECUTIONConsequential target
06 / EVIDENCE ROOM
What a serious evaluation can inspect.
SIO18 does not publish sensitive internal security material or pretend that a public web page is a data room. It does make the evidence model legible so an evaluator knows what should exist, what is attributable, and which pieces still require customer or independent-party participation.
Signed lineage & manifests
Release manifests, package signatures, source/build digests and clean-room packaging establish which artifact was assessed. Integrity answers “is this the artifact we intended to evaluate?”, not “is every production control externally proven?”
SBOM & package evidence
The engineering line includes SBOM and signed-release evidence surfaces. Public SIO18 does not claim an independently attested software-supply-chain certification from their existence.
Topology, custody & rollback
Deployment plans identify plane locality, credential custody, evidence custody, network posture, upgrade channel, attestation, rollback and revocation expectations. Customer-controlled shadow deployment adds read-only observation before live authority is considered.
Decision and permit evidence
An evaluator can separate identity from delegation, deterministic decision, exact permit, JIT credential and execution receipt. That separation is central to whether an AI agent can exercise consequential power safely.
Revocation, containment & recovery
Security evaluation includes revocation races, quarantine, reserve freeze, recall/recovery planning and explicit restoration boundaries. A successful recovery drill in synthetic engineering evidence is not a claim about measured customer production recovery.
Independent consequence evidence
Execution success remains distinct from independent postcondition verification. Where required evidence is missing, StableMind’s Proof-of-Consequence doctrine fails to UNVERIFIABLE instead of turning incomplete evidence into a green check.
07 / CUSTOMER-CONTROLLED PATH
Trust grows by reducing assumptions.
- 01
Architecture & security review
Start with exact system boundaries, deployment locality, evidence classes, credential custody and unresolved customer inputs. Engineering readiness does not pre-answer a customer security decision.
- 02
Customer-controlled bootstrap
PT03 defines customer-owned deployment profiles, manifest verification, identity/credential-broker bindings, environment attestation, telemetry/evidence custody, rollback and revocation validation. The package is readiness engineering until a customer actually operates it.
- 03
Read-only shadow mode
PD04 defines a customer-controlled, read-only shadow deployment with attributable gates, evidence export, rollback and revocation procedures and no downstream execution. This is the safest place to compare what an existing workflow would do with what current authority actually supports.
- 04
Bounded live activation
Only an explicitly authorized workflow may cross from observation to execution, using customer-controlled identity, exact permits, JIT credentials, consequence controls and immediate revocation. A website account, commercial entitlement or successful security review still creates no machine authority.
- 05
Independent proof & acceptance
Production truth requires attributable evidence from the parties who can actually establish it: customer operators, providers, independent assessors, auditors, red teams and release authorities. StableMind engineering cannot certify its own external reality.
08 / PUBLIC TRUTH
What this page does not claim.
StableMind has deep synthetic engineering around security assurance, deployment modes, customer-controlled shadow operation, signed release evidence, SBOM, revocation, recovery and Proof of Consequence. SIO18 makes those engineering surfaces easier to inspect. It does not transform them into SOC 2, ISO 27001, FedRAMP, regulator approval, third-party penetration-test success, named-customer security acceptance, production deployment, production HSM custody, external proof, revenue or customer value.
A future independent certification can be published when an attributable external authority actually issues it. A future customer deployment can be published when the customer and evidence permit that claim. Until then, the absence remains visible.
SIO19 · ACCOUNT & IDENTITY
See the boundary before you connect the workflow.
SIO19 introduces the commercial identity and organization bootstrap as a separate account plane. A StableMind account remains separate from machine authority, and SIO21 remains the first governed-action experience.
Enterprise evaluation
Need a diligence path that keeps approval separate from authority?
Use the source-backed Enterprise Evaluation Room to review security, architecture, deployment, procurement, evidence and pilot design without turning evaluation completeness into production proof.
Open Enterprise Evaluation