# [RFC] TealTiger v1.3 — Governance Workflows & Policy Packs (TealFlow, OWASP Packs, Operating Model)

[nagasatish007]

[RFC] TealTiger v1.3 — Governance Workflows & Policy Packs (TealFlow, OWASP Packs, Operating Model)

Status: OPEN FOR FEEDBACK
Covers: Requirements 3, 6, 8, 16
Target audience: Governance teams, compliance officers, platform teams, DevSecOps

---

Summary

Governance shouldn't require writing code. v1.3 introduces declarative YAML workflows (TealFlow), pre-built policy packs mapped to standards, and a complete enterprise operating model with personas, lifecycle processes, and adoption guides. The goal: governance teams can author, review, and deploy policies without touching application code.

---

Proposed Capabilities

Secure Change Governance (Req 3)

• CODE_CHANGE action class with attributes: target paths, branch, change type, diff hash
• Path allowlists and branch allowlists for AI code agents
• Two-person rule for code changes (second identity must approve)
• Evidence artifact per decision (diff hash, policy version, outcome, approvers)

OWASP Agentic Top 10 Policy Pack (Req 6)

• Pre-built policy pack at policy-packs/owasp-agentic-top10/
• Controls mapped to each of the 10 OWASP Agentic categories
• Stable reason codes per control, traceable to OWASP source
• Zero-config loading (just specify pack name)
• Extensible without modifying shipped files

TealFlow — Declarative Governance Workflows (Req 8)

• YAML-based workflows with: triggers, jobs, steps, conditionals, dependencies
• Event triggers: agent_action, schedule (cron), workflow_dispatch (manual), policy_violation
• Sequential steps within jobs, parallel independent jobs
• needs dependencies between jobs
• if conditionals evaluating action attributes, risk scores, env vars, agent identity
• uses syntax for reusable governance actions (local or remote registry)
• Org-level workflow inheritance (team workflows cannot weaken org controls)
• Encrypted secrets in workflow steps (never exposed in logs)
• Round-trip property: parse → print → parse produces equivalent object

Enterprise Operating Model (Req 16)

• 6 governance personas defined (Author, Approver, Platform Engineer, Developer, Auditor, Incident Responder)
• RACI matrix for governance activities
• Policy lifecycle: DRAFT → REVIEW → APPROVED → ENFORCED → DEPRECATED → RETIRED
• Change process, exception process, rollback process documented
• Day-0/Day-1/Day-2/Emergency operational workflows
• Phased adoption guide (REPORT_ONLY → MONITOR → ENFORCE)
• Two adoption models: Governance-First (recommended) and Developer-First (transitional)

---

Questions for the Community

1. TealFlow syntax — The workflow YAML is inspired by GitHub Actions syntax. Is that familiar enough, or would you prefer something closer to OPA/Rego, Kubernetes manifests, or something else?

2. Org-level inheritance — "Team workflows cannot weaken org controls" — is this the right default? Are there cases where a team legitimately needs to relax an org-level control (with approval)?

3. Policy packs — Beyond OWASP Agentic Top 10, what standards would you want pre-built packs for? (SOC2, PCI-DSS, HIPAA, ISO 27001, EU AI Act, internal company standards?)

4. Code change governance — If you're using AI code agents (Copilot, Cursor, Devin, etc.), what governance controls would you want? Path restrictions? Branch restrictions? Mandatory review? Something else?

5. Adoption model — Would your organization start with Governance-First (central team defines policies, developers consume read-only) or Developer-First (developers integrate SDK, governance added later)?

6. Operating model — Are the 6 personas sufficient? Is there a role in your org that doesn't map to these?

---

How to Give Feedback

• Comment below with thoughts, concerns, or use cases
• React with 👍 on capabilities you'd use
• React with 🤔 on capabilities that seem unclear
• React with 👎 on capabilities you think are wrong

---

Full Spec Reference

See Requirements 3, 6, 8, and 16 in the complete specification