Arckit Agile Security

You are helping an enterprise architect create an Agile Security document using Open Agile Architecture (O-AA, C208) — Axiom 16 Secure by Design, C208 Ch. 4.6, and the O-AA Security Playbook (G216). This approach embeds security into the product sprint rhythm rather than treating it as a separate gate or phase — security becomes a backlog item, not an afterthought.

User Input

$ARGUMENTS

Trigger Guidance

Use this command when any of the following conditions are met:

• Client wants security embedded in sprint rhythm rather than separate security phases

• Product requires continuous compliance evidence generated alongside development artifacts

• Threat modeling needs to be a backlog item, not a one-time activity

• Client operates in regulated environments (APRA, GDPR, APP, AI Act) with sprint-aligned compliance

• Product involves AI/ML systems requiring algorithmic transparency and bias assessment per sprint

Do NOT use when:

• Client requires traditional security audit with separate audit phases — use full TOGAF ADM with dedicated security phase

• Multi-year security programme with 50+ review gates outside sprint cadence

• Client needs standalone penetration testing or security assessment (use dedicated security tools instead)

Prerequisites: Read Foundational Artifacts

Note: Before generating, scan projects/ for existing project directories. For each project, list all ARC-*.md artifacts, check external/ for reference documents, and check 000-global/ for cross-project policies. If no external docs exist but they would improve output, ask the user.

RECOMMENDED (read if available, note if missing):

• PRIN (Architecture Principles, in 000-global) — Extract: Security principles, compliance requirements, data classification standards

  • If missing: warn user to run $arckit-principles first

• OAPR (Agile Product Architecture) — Extract: Product mission, guardrails, technology constraints

  • If missing: note that product architecture context is limited

• OAAL (O-AA ADM Lite) — Extract: Sprint plan, governance cadence, compliance mapping

  • If missing: note that O-AA Lite context is not available

• OASTR (Agile Strategy Canvas) — Extract: Risk profile, transformation risks, security strategy

  • If missing: note that strategy context is limited

Prerequisites 1b: Read external documents and policies

• Read any external documents listed in the project context (external/ files) — extract security policies, compliance requirements, threat models, regulatory obligations

• Read any enterprise standards in projects/000-global/external/ — extract security standards, data classification policies, incident response procedures

Instructions

1. Identify or Create Project

Identify the target project from the hook context. If the user specifies a project that doesn't exist yet, create a new project:

1. Use Glob to list projects/*/ directories and find the highest NNN-* number (or start at 001 if none exist)
2. Calculate the next number (zero-padded to 3 digits, e.g., 002)
3. Slugify the project name (lowercase, replace non-alphanumeric with hyphens, trim)
4. Use the Write tool to create projects/{NNN}-{slug}/README.md with the project name, ID, and date
5. Also create projects/{NNN}-{slug}/external/README.md with a note to place external reference documents here
6. Set PROJECT_ID = the 3-digit number, PROJECT_PATH = the new directory path

2. Read Template

Read the template (with user override support):

• First, check if .arckit/templates-custom/agile-security-template.md exists in the project root

• If found: Read the user's customized template (user override takes precedence)

• If not found: Read .arckit/templates/agile-security-template.md (default)

• Then, read .arckit/templates/_partials/RENDERING.md and resolve the template's <!-- DOC-CONTROL-HEADER --> marker to the Document Control partial it selects, applying the ${organisation_name} and ${default_classification} substitutions. Remove the marker and its comment from the output — a rendered artefact must never contain either.

• Also apply the O-AA placeholder substitutions in .arckit/references/placeholder-substitutions.md (${project_issue_prefix}, ${safety_checklist_id}, ${references_dir}) wherever they appear in the template.

Tip: Users can customise templates with $arckit-customize agile-security

3. O-AA Agile Security Framework

O-AA agile security practice (C208 Axiom 16, Ch. 4.6, G216) establishes that:

• Security as backlog items: Security work enters the product backlog as epics/features/stories — not a separate security workstream

• Sprint-aligned compliance: Compliance evidence is generated continuously alongside development artifacts, not accumulated for end-of-phase audits

• Threat modeling per sprint: Each sprint cycle includes threat model updates as a backlog item, not a one-time activity at project start

• O-AA Axiom 16 (Secure by Design): security controls are designed into the product from Sprint 0, proportional to product risk — not bolted on at a compliance checkpoint

• Shared security ownership: Security is the team's responsibility, not a dedicated security team's gate

4. Shared Artefact Definitions

The agile security command defines artefacts whose structure is inlined in agile-security-template.md:

• security-backlog.yaml — security epics, stories, and sprint capacity allocation

• threat-model.yaml — per-sprint threat model (STRIDE or equivalent)

• compliance-evidence.yaml — sprint compliance evidence, always current

• vision.yaml — architecture vision security constraints (inherited from $arckit-oaa-adm-lite)

5. Generate Agile Security Document

Create the Agile Security document following the template structure.

Document Control

• Generate Document ID with node scripts/generate-document-id.mjs {P} OASEC --filename (canonical form: ARC-{P}-OASEC-v1.0)

• Set owner, dates, status, classification

• Review cycle: Per sprint cycle

Security Backlog Integration

• Security epic categories: Data protection, authentication/authorization, encryption, monitoring/observability, incident response, compliance reporting

• Sprint capacity: Target 20-30% of sprint capacity for security items (adjust based on risk profile)

• Security story format: "As a [role], I want [security control] so that [threat mitigated]"

• Acceptance criteria: Each security story includes testable security acceptance criteria

Threat Modeling per Sprint

• Sprint 0 threat model: Initial threat model covering product architecture (STRIDE or equivalent)

• Sprint N threat updates: Each sprint updates threat model based on new features, identified vulnerabilities, and environment changes

• Threat model as backlog item: "Update threat model for Sprint N features" enters backlog each sprint

• Automated threat detection: Integration with SAST/DAST tools feeding threat model updates

Compliance Evidence per Sprint

• Evidence generation: Compliance evidence artifacts generated alongside feature development

• Regulatory mapping: Map sprint deliverables to regulatory requirements (GDPR, APRA, APP, AI Act)

• Continuous evidence: Evidence is never accumulated for audits — it's always current

• Evidence structure: Standardized evidence format per sprint, inlined in agile-security-template.md

Security Architecture Guardrails

• Non-negotiable constraints: Data encryption at rest/in transit, authentication requirements, logging standards

• Technology standards: Approved security building blocks and libraries

• Anti-patterns: Forbidden security approaches (e.g., rolling your own crypto, hardcoded credentials)

• Security review gates: Lightweight sprint-level security reviews, not heavy-gate audits

AI/ML Security Considerations

• Algorithmic transparency: ATRS compliance per sprint for AI/ML features

• Bias and fairness: Automated bias testing in sprint CI/CD pipeline

• Model security: Model poisoning, data leakage, and adversarial attack mitigations

• Privacy preservation: Differential privacy, federated learning where applicable

6. External References

Populate the ## External References section per .arckit/references/citation-instructions.md. Every claim taken from an external/ document, a projects/000-global/external/ policy, or a web source MUST carry an inline [DOC_ID-CN] citation marker resolving to a Document Register row. The Open Group Open Agile Architecture standard (C208) MUST appear in the Document Register with its primary URL and the verification date.

7. Quality Gate

Before writing the file, read .arckit/references/quality-checklist.md and verify all Common Checks plus the OASEC per-type checks pass. Fix any failures before proceeding.

8. Write the Document

IMPORTANT: The Agile Security document will be a substantial document (typically 180-300 lines). You MUST use the Write tool to create the file, NOT output the full content in chat.

Create the file at:

projects/{P}/ARC-{P}-OASEC-v1.0.md

9. Show Summary to User

After writing the file, show a concise summary (NOT the full document):

## Agile Security Document Created

**Document**: `projects/{P}/ARC-{P}-OASEC-v1.0.md`
**Document ID**: ARC-{P}-OASEC-v1.0

### Security Backlog Profile
- **Security epic categories**: [N] categories defined

- **Sprint capacity target**: [X]% of sprint capacity

- **Regulatory mappings**: [N] frameworks mapped (GDPR, APRA, etc.)

### Threat Modeling
- **Initial threat model**: [N] threat categories, [N] identified threats

- **Per-sprint updates**: Threat model backlog item defined

- **Automated detection**: [Tools/integrations configured]

### Compliance Evidence
- **Evidence per sprint**: [N] evidence categories

- **Regulatory coverage**: [Frameworks covered]

- **Continuous audit trail**: [Evidence generation approach]

### Sprint Artifacts
- ✅ security-backlog.yaml

- ✅ threat-model.yaml

- ✅ compliance-evidence.yaml

### Synthesised From
- [✅/⚠️] Architecture Principles: ARC-000-PRIN-v[N].md

- [✅/⚠️] Product Architecture: ARC-{P}-OAPR-v[N].md

- [✅/⚠️] O-AA ADM Lite: ARC-{P}-OAAL-v[N].md

- [✅/⚠️] Agile Strategy: ARC-{P}-OASTR-v[N].md

### Next Steps
1. Create security epics for Sprint 0
2. Run initial threat model: STRIDE analysis for product architecture
3. Establish governance cadence: `$arckit-agile-governance`
4. Configure CI/CD security pipeline integration

**File location**: `projects/{P}/ARC-{P}-OASEC-v1.0.md`

Important Notes

1. Security as Backlog Items: Security is not a phase or gate in O-AA. It's backlog items that compete with feature work for sprint capacity. The team decides security priority alongside feature priority.

2. Sprint-Aligned Compliance: Compliance evidence is generated continuously. You never "catch up" before an audit — evidence is always current because it's produced alongside every sprint deliverable.

3. Threat Modeling is Living: The threat model updates each sprint. It's not a document you write once at project start. New features create new attack surfaces.

4. Sprint Artefacts: The security-backlog.yaml, threat-model.yaml, and compliance-evidence.yaml structures are defined inline in agile-security-template.md. Validate artefacts against those structures; they stay consistent with the traditional TOGAF commands without sharing schema files.

5. Use Write Tool: The Agile Security document is typically 180-300 lines. ALWAYS use the Write tool to create it.

6. Version Management: If an Agile Security document already exists (ARC-*-OASEC-v*.md), create a new version (v2.0) rather than overwriting.

7. Markdown escaping: When writing less-than or greater-than comparisons, always include a space after < or > (e.g., < 3 seconds, > 99.9% uptime) to prevent markdown renderers from interpreting them as HTML tags or emoji.

Suggested Next Steps

After completing this command, consider running:

• $arckit-agile-governance -- Establish governance cadence including security review gates
• $arckit-agile-strategy -- Align security strategy with dual transformation tracks