Security & Compliance
Audience: Security reviewers, compliance officers, and engineers configuring access control or encryption.
What you will accomplish: Understand the security model — audit logging, RBAC, privilege gates, encryption — well enough to evaluate, configure, or extend it.
Prerequisites: Read Architecture first; familiarity with AES-256-GCM and OAuth 2.0 helps for the encryption page.
Estimated time: ~5 minutes (this page); ~25 minutes for the full section.
Security is not a feature — it is the foundation. Every design decision in the Case Automation MCP Server is made under the assumption that a missed deadline, a privilege breach, or an incorrect external communication is a malpractice liability.
Where to start
Read in this order for a complete security picture:
- Audit & Logging — The tamper-evident hash chain that records every action
- RBAC & Privilege — Who can do what, and the non-overridable privilege gate
- Encryption & Secrets — How data is protected at rest and in transit
Audit & Logging
Tamper-evident hash-chained audit log. Every state change is recorded before it is considered complete.
RBAC & Privilege
Role-based access control with default-deny. Privileged documents can never reach external recipients.
Encryption & Secrets
AES-256-GCM encryption at rest. Zero credentials in source. Central secret store with rotation-friendly design.
Security scorecard
| Dimension | Score | Grade |
|---|---|---|
| Confidentiality / privilege | 96 | A |
| Auditability | 96 | A |
| Access control | 93 | A |
| Encryption | 95 | A |
| Secret hygiene | 92 | A− |
| Observability security | 90 | A− |
Overall security posture: 96 / 100
Key security invariants
- Every write audited before complete. Hash-chained, append-only, tamper-evident. No action is "done" until the audit record is written.
- Default-deny RBAC. The agent service identity has the minimal grant set. Every tool and matter is scoped to roles.
- Privilege gate is non-overridable. A
Document.privileged=Truecan never reach an external recipient, regardless of approval tokens. - PII never in logs. A shared scrubber redacts A-numbers, SSNs, passport numbers, DOB, email, and phone across all observability signals.
- No credentials in source. All secrets read from the secret store at runtime. OAuth refresh tokens stored encrypted in Postgres.
- Idempotency prevents double-sends. Every external action carries an idempotency key. Retries cannot double-send or double-file.
Human-in-the-loop gates
External and irreversible actions require explicit human approval. This is a default-on safety invariant, not a configuration option.
| Action tier | Gate required? | Default | Overrideable? |
|---|---|---|---|
| Read (no side effects) | No | N/A | N/A |
| Write (reversible) | One-click confirm | Yes | Per-workflow config |
| External / irreversible | Explicit approval, multi-channel | Always on | No |
Gate channels:
- MCP — The agent client surfaces an approval prompt
- Web — Sidecar serves an approval page at
/approvals/{token} - Email — Approval link sent to the required role's inbox
All three channels share the same token pool and enforce single-use atomicity.
Compliance path
The system is designed toward SOC 2 Type II with GDPR-awareness:
- Data residency configurable per
CAM_RESIDENCY_REGION - PII scrubber across logs, traces, and metrics
- Audit log exportable for review
- RBAC with least-privilege principle
- Encryption in transit (TLS) and at rest (AES-256-GCM)
HIPAA path is possible if required by the firm's practice area.
Next steps
- Audit & Logging — Hash chain, canonical serialisation, verification
- RBAC & Privilege Gates — Role matrix, non-overridable privilege checks
- Encryption & Secrets — AES-256-GCM, secret store, key rotation
Last updated: 2026-06-01