Encryption at Rest Design AGENTS.md Template

Overview

This AGENTS.md Template describes an encryption at rest design workflow for AI coding agents. It governs both single-agent implementations and multi-agent orchestration. The template codifies roles, handoffs, tool governance, and security constraints to ensure data at rest is protected across environments and regions. It provides a concrete operating manual so teams can align on memory, sources of truth, and escalation paths while enabling clear agent collaboration.

When to Use This AGENTS.md Template

When designing encryption at rest workflows for AI data and model artifacts
When implementing or evaluating a multi-agent orchestration pattern for key management and data protection
When you need explicit handoff rules, memory rules, and source-of-truth governance

Copyable AGENTS.md Template

# AGENTS.md

Project role
- Encryption at rest design program for AI coding agents
- Responsible for defining key hierarchy, data classifications, and policy alignment

Agent roster and responsibilities
- Planner: define goals, data classifications, and compliance constraints
- Architect: design KMS/HSM integration and envelope encryption model
- KeyManager: manage master keys, rotation, access controls
- CryptoEngine: perform encryption and decryption using envelope keys
- Auditor: ensure logs, audits, and retention meet policy
- Reviewer: security validation and policy alignment
- Tester: validation of encryption flows and edge cases
- Deployment: runtime configuration and secret handling

Supervisor or orchestrator behavior
- Orchestrator enforces policy, tracks context, and triggers handoffs
- Maintains a secure memory of decision artifacts and references to source of truth

Handoff rules between agents
- Planner completes encryption design spec -> Architect implements integration
- Architect passes key management plan to KeyManager
- KeyManager authorizes data keys to CryptoEngine for encryption tasks
- CryptoEngine returns results to Auditor and Reviewer for validation
- Deployment applies validated configurations to production

Context, memory, and source-of-truth rules
- All decisions reference policy documents and cryptographic requirements
- Store context in a secure memory store and reference the canonical configuration repo
- Never duplicate sensitive data in memory; fetch only as needed with ephemeral access

Tool access and permission rules
- Access cloud KMS and HSM through approved APIs
- Secrets retrieved via secure vaults; do not hardcode or cache plaintext secrets
- Logs must never contain plaintext keys or data

Architecture rules
- Envelope encryption with a Data Key (DEK) encrypted by a Key Encryption Key (KEK)
- Key hierarchy: KEK -> DEK -> ciphertext data
- Rotation and regional replication policies must be explicit

File structure rules
- Use a dedicated folder encryption-at-rest-design with subfolders: policies, configs, keys, scripts, tests, docs

Data, API, or integration rules when relevant
- Encrypt all data at rest using standard cipher suites; decrypt only in secure compute
- All data in transit protected by TLS; API calls authenticated and authorized

Validation rules
- Validate encryption and decryption cycles; test key rotation paths
- Verify access controls; ensure least privilege

Security rules
- Do not expose keys or plaintext
- Enforce auditing and anomaly detection on key usage
- Rotate keys on defined schedule or upon detected risk

Testing rules
- Unit tests for crypto primitives; integration tests for end-to-end flows
- Regression tests for rotation and handoffs

Deployment rules
- Secrets management integrated into CI/CD; secrets scanned before deployment
- Rollback procedures for failed rotations or misconfigurations

Human review and escalation rules
- Security lead must approve unusual key usage or policy deviations
- Escalate to Security Steering Committee when necessary

Failure handling and rollback rules
- On failure, rollback to previous stable key state; reprocess affected data if needed
- All steps are idempotent and auditable

Things Agents must not do
- Do not expose plaintext, bypass policy constraints, or skip reviews
- Do not perform unsanctioned changes in production

Recommended Agent Operating Model

Planner defines objectives and constraints; Architect implements the technical design; KeyManager enforces key lifecycle and access controls; CryptoEngine executes cryptographic operations; Auditor validates compliance; Reviewer provides security validation; Tester ensures correctness; Deployment applies configurations to runtime systems. Escalation paths exist for policy violations or security incidents. Decision boundaries are explicit: no crypto operation without a validated plan and approved configuration snapshot.

Recommended Project Structure

encryption-at-rest-design/
├── policies/
├── configs/
├── keys/
├── scripts/
├── tests/
└── docs/

Core Operating Principles

Operate from a single source of truth for policy and configuration
Enforce explicit handoffs with verifiable artefacts
Guard secrets and keys; do not leak plaintext
Maintain auditable trails for all actions
Ensure idempotent operations across retries
Limit tool access to least privilege

Agent Handoff and Collaboration Rules

Planner to Architect: deliver encryption goals, data classifications, and policy constraints. Architect to KeyManager: deliver KEK/DEK hierarchy, rotation policy, and access controls. KeyManager to CryptoEngine: deliver encrypted keys and access tokens for cryptographic operations. CryptoEngine to Auditor/Reviewer: deliver operation logs and validation results. Deployment: enforce configuration and secret propagation in production with approvals.

Tool Governance and Permission Rules

Execute only approved KMS/HSM APIs
Secret retrieval via vaults; ephemeral use only
Access controls audited; no plaintext stored in memory
Change management requires security sign-off
Production changes require staging validation and approvals

Code Construction Rules

Crypto primitives use standard libraries with verified security updates
Key rotation scripts idempotent and auditable
Configuration as code with versioning and approvals

Security and Production Rules

Encrypt all data at rest via envelope encryption
Enable detailed key usage auditing and anomaly alerts
Rotate KEK/DEK per policy or risk signal
Never log plaintext or keys

Testing Checklist

Crypto correctness tests: encryption and decryption accuracy
Rotation flow tests and rollback tests
Access control and secret management tests
End-to-end encryption tests in staging

Common Mistakes to Avoid

Storing plaintext in logs or memory
Skipping reviews or bypassing policy gates
Assuming rotation is optional
Overlooking cross-region key management concerns
Ignoring incident response for key compromise

FAQ

What is the purpose of this AGENTS.md Template?

The template standardizes encryption at rest design workflows for AI coding agents, defines roles, handoffs, and tool governance to enable secure multi-agent orchestration.

How are agent handoffs defined?

Handoffs follow a fixed sequence: Planner, Architect, KeyManager, CryptoEngine, Auditor/Reviewer, Deployment, with explicit completion criteria and artifact transfer.

What are the primary security constraints?

Do not leak keys or plaintext; use envelope encryption; secrets retrieved securely; maintain audit trails; enforce rotation and least privilege.

How is validation performed?

Unit tests for crypto, integration tests for end-to-end flows, and CI gates for security checks; all changes validated before production deployment.

What happens on failure or rollback?

Rotate back to the last valid key, reprocess data if needed, and escalate to security leads if issues persist; ensure idempotent rollback paths.

Target User

Use Cases