📖Summary

The Security service is built following the [agent-centric modular architecture](/dev/carolopedia/wiki/architecture) of Carolverse. It leverages agile principles to build and operate security as software using distinct agent identities, each carrying out a specific defensive activity — so that the agents who run Carolverse are also the agents who defend it.

📖Functional considerations

Security is the connective tissue of the whole ecosystem, so its architecture is shaped by what it must guarantee end-to-end:

- **Defence-in-depth, not a single wall.** Identity & access, security operations, governance, product security, and data protection are independent layers; a failure in one must not collapse the others.
- **Least privilege by construction.** Every agent can perform ONLY its own privileged work — access is the exception that must be requested, granted, and expired, never the default.
- **No standing privilege.** Powerful access is just-in-time: brokered on demand and torn down when the task ends, so there is no permanent attack surface to steal.
- **Accountable by identity.** Every privileged action runs as a known OS identity and is verified before it executes, so each action is attributable to one agent.
- **A gate on the way into production.** Build-time security and privacy review must sit on the path that ships code, so a change cannot reach production while bypassing the checks.
- **Personal data stays isolated.** User memory and PII are partitioned per user and never leak across the boundary.

📖Solution architecture

The service is **defence-in-depth realised as blocks** — the layers shown in the Blocks section of the service page — each owned by a dedicated head and carried out by that head's run-audited droids. It is a direct instance of Carolverse's [agent-centric modular architecture](/dev/carolopedia/wiki/architecture): see the service's team and blocks above rather than a roster repeated here.

- **A structural identity foundation.** The registry RBAC schema (roles → permissions → grants) is the single layer that decides authorisation; every other surface reads it.
- **Privileged execution through dedicated identities.** A locked OS user per agent owns that agent's privileged write surface; an owner-daemon runs as that user and only executes commands from a verified queue — so privilege is split, attributable, and never blanket.
- **Just-in-time access as the broker.** Powerful grants are issued on request, time-boxed, and auto-expire; standing access is the exception, not the rule.
- **A build-time gate.** Product security and privacy review sit on the path into production, scanning for secrets, vulnerabilities, and PII exposure before a change ships.
- **Continuous watch and recovery.** Session and threat monitoring, incident response, and resilience drills run on a schedule so detection and recovery are part of the system, not a manual afterthought.
- **Governance closes the loop.** Policies, the risk register, periodic recertification, and segregation-of-duties enforcement keep the live grants honest against the rules.

📖Design principles

- **Least privilege by default.** An agent gets exactly its own privileged surface and nothing more — access is granted, not assumed.
- **No standing privilege.** Powerful access is just-in-time and expires; there is no permanent grant to compromise.
- **Separation of duties.** The agent that does the work is not the agent that authorises or recertifies it; defence is split across independent heads.
- **Single source of truth.** Authorisation comes from the registry RBAC schema and design store, never hand-copied — the shared principle described on the [Carolverse Architecture](/dev/carolopedia/wiki/architecture) page.
- **Accountable by identity.** Every privileged action runs as a known OS user through a verified queue, so it is attributable to one agent.
- **Shift left.** Security and privacy review gate the build, catching issues before production rather than after.
- **Agent-centric modular architecture.** Every defensive layer has an accountable agent and a doing droid.

📖What it delivers today

- **Per-agent OS identities and privileged execution.** Locked per-agent users with owner-daemons serving a verified request queue, so each agent does only its own privileged work — Radagast's User Management layer (the User Management head in the blocks above).
- **Identity & access platform.** The registry RBAC schema, just-in-time expiring access, and the credential vault with rotation — run directly by the owner, [Heimdall](/dev/carolopedia/wiki/agent/agt-038).
- **Security operations and resilience.** JIT brokering and expiry, continuous session and threat monitoring, incident response, and business-continuity / disaster-recovery drills — [Tyr](/dev/carolopedia/wiki/agent/agt-039)'s SecOps block.
- **Governance, risk and compliance.** The security policy set, the risk register, periodic access recertification, and segregation-of-duties enforcement — [Forseti](/dev/carolopedia/wiki/agent/agt-040)'s GRC block.
- **Product security.** The build-time security review gate, secret and vulnerability scanning, and supply-chain security — [Vidar](/dev/carolopedia/wiki/agent/agt-041)'s ProdSec block.
- **Data protection and privacy.** PII guarding, user-memory isolation, data classification and retention, and the privacy review gate — [Var](/dev/carolopedia/wiki/agent/agt-042)'s Data Protection block.

📖What it will deliver

- Auto-recertification that proposes and files revocation initiatives for orphaned or excess grants rather than only flagging them.
- A unified threat-and-access dashboard spanning all six layers.
- Periodic, scheduled resilience (disaster-recovery) drills with audited outcomes feeding the risk register.
- Tightening JIT windows further so the default grant lifetime shrinks toward the minimum a task needs.