The security service
The security service is the enforcement and evidence plane of a cell.
Where system provisions the cell's first keys, security runs
the ongoing crypto lifecycle, the certificate authorities, rotation,
custody, and revocation, and it is the home of the platform's policy
enforcement, threat detection, SIEM, response, and compliance capabilities.
Feeds: Security Platform.
What it owns
- Crypto lifecycle: key rotation, renewal, and revocation over the life of the cell.
- Certificate authorities: the CAs that issue and vouch for the identities everything else presents.
- Key Custody: custody and controlled release of key material.
- Enforcement policy: the policy that authorization and the refusal gate evaluate.
- Threat detection: detection of hostile and anomalous activity.
- SIEM: the tamper-evident audit and security-information plane; see SIEM.
- Response: response and containment actions.
- Compliance: attestation and compliance evidence.
Sub-modules (public names)
| Sub-module | What it does |
|---|---|
| Certificate authorities | Issue and vouch for cell and entity identities |
| Crypto lifecycle | Rotate, renew, and revoke keys over the cell's life |
| Key Custody | Hold and controllably release key material |
| Enforcement Policy | The policy evaluated at every authorization decision |
| Capability Control | Attenuable capability grants for principals, including agents |
| Threat Detection | Detects hostile and anomalous activity |
| SIEM | Tamper-evident audit and security information; see SIEM |
| Security & Operations | The security operations console surface |
| Data Security Posture | Posture assessment for data-plane controls |
| Identity Federation | Federating identity across organizations; see identity |
| Session Administration | Administering live sessions and their revocation |
APIs and surfaces
security is not externally exposed. Its HTTP and gRPC control surfaces bind
loopback (clear) and an internal mutual-TLS interface requiring a client
certificate; external access is only ever through the node gate.
Because security is the authority the other services consult, it is a
depends_on of nearly every service in the cell's boot sequence.
Workers
Background workers cover certificate rotation and expiry, revocation propagation, audit-chain maintenance, detection pipelines, and compliance evaluation. They run per cell with no coordinator.
The evidence chain
Figure: the enforcement and evidence flow. Certificate authorities and the hash-chained SIEM record are drawn verified (green); the authorization / refusal gate is drawn amber because its defining behaviour is that it can refuse. Ceiling: refusal and hash-chained audit with counted gaps are shown; behavioural threat scoring is a detection input, not a claim of prediction.
Table equivalent
| From | Relationship | To | State |
|---|---|---|---|
| Certificate authorities | vouch for identity into | Authorization / refusal gate | verified |
| Enforcement policy | is evaluated by | Authorization / refusal gate | neutral |
| Authorization / refusal gate | records every decision to | SIEM | refusal-capable |
| Threat detection | feeds | SIEM and Response | neutral |
| Response | records actions to | SIEM | verified record |
In the deployment matrix
security runs identically in every corner. Single-cell, the CA and audit chain
are wholly local. Multi-cell, revocation and federation propagate across cells,
and each cell keeps its own tamper-evident chain with counted gaps rather than a
shared mutable log. Sovereign / air-gapped, the entire lifecycle, issuance,
rotation, detection, audit, runs with no external dependency, which is the
corner the product is sold on.
Related topics
- Security Platform, the customer-facing area this service carries.
- Cryptography · SIEM · Governance · Compliance.
- Ports & protocols reference.