Security Governance
Manage secrets, access, dependencies, permissions, and approval rules in enterprise projects.
Key takeaways
- Security governance turns risk into routine rules visible in development, CI, deployment, and incident response, not bolted on after an audit.
- Governance areas cover secrets, access, authentication, authorization, dependencies, and data classification, each with a required rule.
- Changes touching auth, roles, tenant boundaries, payments, secrets, or third-party data sharing require explicit review.
- Never commit or paste production secrets, rotate exposed credentials immediately, and audit env vars during deployment changes.
- Codex teams enforce agent rules via
requirements.toml: approval policies, sandbox modes, filesystem deny_read, prefix rules, and MCP allowlists.
Security governance turns risk into routine operating rules. It should be visible in development, CI, deployment, and incident response, not added only after an audit.
Governance Areas
| Area | Required rule |
|---|---|
| Secrets | Store in approved secret managers or platform env vars |
| Access | Grant least privilege and review regularly |
| Authentication | Define supported identity providers and session policy |
| Authorization | Keep role and permission checks close to protected actions |
| Dependencies | Review vulnerable or abandoned packages |
| Data | Classify sensitive data and logging restrictions |
Change Review
High-risk changes require explicit review when they touch:
- Authentication or session logic.
- Authorization, roles, or tenant boundaries.
- Payment, billing, or customer data.
- Secrets, environment variables, or deployment config.
- Logging, analytics, or third-party data sharing.
Secret Handling Rules
- Never commit secrets to the repository.
- Do not paste production secrets into issue trackers or chat logs.
- Rotate exposed credentials immediately.
- Keep local development secrets separate from production credentials.
- Audit environment variables during deployment changes.
Security Metrics
| Metric | Purpose |
|---|---|
| Open critical vulnerabilities | Dependency risk |
| Secret scan findings | Credential handling quality |
| Access review completion | Permission hygiene |
| Incident time to contain | Operational readiness |
| Policy exceptions | Governance debt |
Agent Governance
| Layer | Rule |
|---|---|
| Filesystem | Deny reads for secrets, private data, and regulated exports |
| Commands | Forbid destructive commands and prompt before git history changes |
| MCP | Allow only approved MCP servers and tool identities |
| Review | Require human or automatic approval for sensitive actions |
| CI | Enforce tests, ownership, and deployment gates after agent changes |
Codex teams can enforce these rules with requirements.toml, including allowed approval policies,
sandbox modes, web search modes, managed hooks, command rules, and MCP allowlists.
allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
allowed_web_search_modes = ["cached"]
[permissions.filesystem]
deny_read = ["./.env*", "./private/**"]
[rules]
prefix_rules = [
{ pattern = [{ token = "rm" }], decision = "forbidden", justification = "Use an explicit cleanup script instead." },
]