OWASP Production Readiness AGENTS.md Template - AGENTS.md Template

Overview

This AGENTS.md template is designed for OWASP production readiness, governing a secure, auditable workflow for AI coding agents that operate both as individuals and in multi-agent orchestration. It formalizes roles, handoffs, tool governance, and human review to ensure secure, compliant production deployments.

Direct answer: Use this AGENTS.md template to deploy an auditable, OWASP-aligned agent network with explicit responsibilities, stateful memory, and escalation paths that protect production integrity.

When to Use This AGENTS.md Template

• You need an auditable, OWASP-aligned production readiness workflow for AI coding agents.
• You require clear agent roles, handoffs, and governance to prevent context drift and unsafe automation.
• You must integrate vulnerability management, SBOM collection, and secure deployment gates into the agent workflow.
• You want a repeatable template that scales from single-agent runs to multi-agent orchestration with human review checkpoints.

Copyable AGENTS.md Template

Copy the block below into a file named AGENTS.md at the project root to establish the operating context for single-agent or multi-agent work.

# AGENTS.md

Project: OWASP Production Readiness
Description: This AGENTS.md template governs an OWASP-aligned, production-ready workflow for AI coding agents, enabling secure, auditable multi-agent orchestration with explicit handoffs and governance.

Agent roster and responsibilities:
- Planner: designs the production readiness plan, aligns threat modeling with OWASP ASVS, defines gating criteria, and approves task allocation.
- Implementer: integrates tools, enforces OWASP controls in code and pipelines, and implements artifacts from the plan.
- Reviewer: performs security/compliance review against OWASP Top Ten, organization policies, and artifact quality checks.
- Tester: executes unit, integration, and security tests; validates that gating criteria are met before deployment.
- Researcher: collects threat intel, SBOM data, CVE feeds, and supports domain-specific OWASP controls.
- Domain Specialist: ensures project-specific OWASP requirements are properly applied to the domain context.

Supervisor or orchestrator behavior:
- The Orchestrator coordinates task routing, enforces gating criteria, records decisions, and archives artifacts for auditability.
- It enforces the lifecycle: plan & assign → execute → review → test → deploy → monitor; and triggers escalation when gates fail.

Handoff rules between agents:
- Planner → Implementer: after plan validation and artifact definition.
- Implementer → Reviewer: after build artifacts and changes are produced.
- Reviewer → Tester: after security/compliance review passes.
- Tester → Orchestrator: after tests complete and results are recorded.
- Orchestrator → Implementer: for fixes on failed tests or gate failures.
- Orchestrator → Domain Specialist: for domain-specific assessments where required.

Context, memory, and source-of-truth rules:
- Context is persistent within the run scope; memory is scoped per sprint/run; source-of-truth is the repository, CI/CD logs, vulnerability databases, and SBOM sources.
- All decisions and outputs must be traceable to artifacts in the repository and the orchestrator’s run record.

Tool access and permission rules:
- Access is restricted by least privilege; secrets reside in a vault; external services require scoped tokens rotated per run.
- Production tooling changes require formal approvals and are logged in the run history.

Architecture rules:
- Favor modular, auditable components; minimize cross-service state; avoid privileged actions without explicit escalation.
- All critical gates must be automated where possible, with explicit human review for exceptions.

File structure rules:
- Place all run context, outputs, and templates under the project root in a version-controlled directory.
- Example structure:
  /OWASP-Prod-Readiness/
  ├── AGENTS.md
  ├── agents/
  │   ├── planner/
  │   ├── implementer/
  │   ├── reviewer/
  │   ├── tester/
  │   ├── researcher/
  │   └── domain-specialist/
  ├── artifacts/
  │   ├── builds/
  │   ├── test-reports/
  │   └── security-reports/
  ├── configs/
  ├── docs/
  ├── tests/
  └── deployment/

Data, API, or integration rules when relevant:
- Data flows should be explicit; use typed interfaces for components; protect PII and secrets; SBOMs must be generated and attached to releases.
- Integrations follow a restricted API surface with versioned contracts.

Validation rules:
- Gate criteria must be satisfied: security checks, dependency license checks, SBOM completeness, and pass of all tests.
- Artifacts must be attached to the run record with traceability to inputs.

Security rules:
- Secrets must never be committed; rotate tokens; encrypt data in transit and at rest; enforce least privilege across all agents.

Testing rules:
- Include unit, integration, security, and performance tests where relevant; tests must pass before deployment gates.

Deployment rules:
- Deploy to a staging environment first; require human sign-off before production deployment; all steps are logged.

Human review and escalation rules:
- Escalate to Security Lead for critical findings; provide a summarized run report with artifacts and justifications.

Failure handling and rollback rules:
- On failure, rollback to the last known good baseline; re-run from the planner stage after fixes; preserve audit trails.

Things Agents must not do:
- Do not deploy to production without gate approval; do not bypass security controls; do not modify governance rules mid-run; do not perform unsanctioned data exfiltration.

Recommended Agent Operating Model

The recommended operating model defines clear roles, decision boundaries, and escalation paths for OWASP production readiness. It enables both single-agent execution and robust multi-agent coordination with explicit handoffs and governance.

• Planner = decide scope, gating criteria, threat-model alignment, and task sequencing.
• Implementer = execute changes, integrate tools, enforce OWASP controls, and produce artifacts.
• Reviewer = validate security posture, OWASP compliance, and artifact quality.
• Tester = verify tests, perform security tests, and confirm gate criteria are met.
• Researcher = supply SBOM, vulnerability data, and domain-specific input.
• Domain Specialist = ensure domain-specific OWASP controls are correctly applied.

Recommended Project Structure

OWASP-Prod-Readiness/
├── AGENTS.md
├── agents/
│   ├── planner/
│   ├── implementer/
│   ├── reviewer/
│   ├── tester/
│   ├── researcher/
│   └── domain-specialist/
├── artifacts/
│   ├── builds/
│   ├── test-reports/
│   └── security-reports/
├── configs/
├── docs/
├── tests/
└── deployment/

Core Operating Principles

• All actions must be traceable to a run and artifacts must be versioned.
• Security and privacy controls are enforced at every gate.
• Decisions are driven by explicit criteria and documented rationale.
• Handoffs are deterministic and auditable with clear owners.
• Escalations occur for any gate failure or security concern.

Agent Handoff and Collaboration Rules

• Planner to Implementer: hand off plan, gating criteria, and artifact specs.
• Implementer to Reviewer: share build, artifacts, and rationale for changes.
• Reviewer to Tester: deliver verified security/compliance verdict.
• Tester to Orchestrator: upload test results and logs for archival.
• Orchestrator to Implementer/Domain Specialist: request fixes or domain-specific adjustments.

Tool Governance and Permission Rules

• Tools access is scoped per role; secrets in a vault; rotation enforced per run.
• Production changes require explicit approvals; all actions are logged and replayable.
• API calls use signed tokens; no hard-coded credentials in code or AGENTS.md blocks.

Code Construction Rules

• Follow OWASP Secure Coding Practices; implement permission checks and input validation.
• Artifacts must be deterministic; avoid non-deterministic randomness without justification.
• All changes are reviewed by at least one Reviewer before deployment.

Security and Production Rules

• Use a dedicated production gateway; separate staging and production credentials.
• Audit logging enabled; retain logs for at least one year; protect PII.
• Continuous monitoring and alerting for abnormal deployment patterns.

Testing Checklist

• Unit tests cover critical OWASP controls; integration tests validate tool integrations.
• Security tests include dependency checks, SCA, and vulnerability scanning.
• End-to-end tests verify gate criteria across the workflow.
• Deployment tests in staging ensure rollback paths function.

Common Mistakes to Avoid

• Skipping OWASP gate checks or bypassing reviewer sign-off.
• Ambiguity in handoff criteria leading to context drift.
• Storing secrets in code or logs; failing to rotate credentials.
• Unclear ownership for domain-specific controls.

Related implementation resources: AI Use Case for Sales Pipeline Reviews and Deal Risk Scoring and AI Use Case for Rental Applications and Document Checks.

FAQ

What is this AGENTS.md template for OWASP production readiness?

It defines a reproducible, auditable operating manual for AI coding agents to gate production readiness using OWASP-aligned controls.

Who should use this AGENTS.md template?

Engineering teams building secure pipelines; security leads; product teams needing governance for AI agents in production.

How are agent handoffs managed?

Through a defined run lifecycle: Planner approves tasks, Implementer builds, Reviewer validates, Tester verifies, and the Orchestrator records outcomes and archives artifacts.

What about tool governance and secrets?

Access is least-privilege, secrets live in a vault, and production changes require approvals and audit logging.

How is failure handled?

Failures trigger rollback to a known good baseline, with a human review path and re-run after fixes.

What should agents avoid doing?

Do not modify governance rules mid-run, bypass security controls, or deploy to production without gate approvals.