# 📢 TealTiger v1.3 RFC — Open for Community Feedback

[nagasatish007]

📢 TealTiger v1.3 RFC — Open for Community Feedback

We're opening the TealTiger v1.3 specification for public review before implementation begins.

What is v1.3?

TealTiger v1.3 ("Governance Bundle") is a major capability expansion that evolves the SDK from runtime enforcement primitives into an enterprise-ready governance layer for autonomous AI agents.

Design principles:

• No LLM in the governance path (deterministic decisions only)
• SDK-only architecture (no infrastructure dependency)
• TypeScript + Python parity
• Apache 2.0 open source
• Backward compatible with v1.2

RFC Threads

We've organized the spec into 5 themed discussions. Pick the ones relevant to your work:

#	Thread	Who Should Read
1	Autonomous Agent Governance — Modes, NHI, Safety Rails, Identity	Platform engineers, security architects
2	Evidence, Proof & Audit — SOC/IR pipelines, TealProof, Tamper resistance	SOC analysts, compliance teams, auditors
3	Detection & Guardrails — OWASP gap closure, ML classifier, Drift detection	Security engineers, red teamers
4	Governance Workflows & Policy Packs — TealFlow, OWASP packs, Operating model	Governance teams, compliance officers
5	Portability, Ecosystem & Enterprise — Lock-in reduction, Integrations, Cost governance	Enterprise architects, FinOps, platform teams

How to Give Feedback

• Comment on any thread with thoughts, concerns, or use cases
• React with 👍 on capabilities you'd use in production
• React with 🤔 on capabilities that seem unclear or over-engineered
• React with 👎 on capabilities you think are wrong or unnecessary

Timeline

• RFC open: May 2026
• Feedback incorporated: Ongoing
• Implementation begins: After design phase

Full Specification

The complete requirements document is available in the repository:https://github.com/agentguard-ai/tealtiger/blob/main/docs/specs/v1.3-requirements.md

Why We're Doing This

We believe governance infrastructure should be built in public. If you're deploying AI agents in production, your pain points should shape what we build — not our assumptions.

Even if you don't comment, browsing the spec gives you visibility into where runtime governance is heading.

---

TealTiger is open-source (Apache 2.0). GitHub: https://github.com/agentguard-ai/tealtiger

[armorer-labs]

The deterministic/no-LLM-in-governance-path principle is the right anchor. The main thing I would look for in v1.3 is a crisp split between detection, policy, and evidence.

A governance bundle becomes much easier to operate if each decision record can answer:

• what identity or non-human identity initiated the action
• what agent/run/turn produced it
• what tool or external side effect was requested
• what data source labels influenced the request
• which policy pack and version evaluated it
• whether the result was allow, deny, require approval, quarantine, or observe-only
• what proof/evidence artifact was emitted

For the detection and guardrails part, I would be careful not to make the ML classifier the authority source. It should be a signal into deterministic policy, with calibrated confidence, reason labels, and an explicit fallback when confidence is low. That keeps the governance story auditable instead of making the classifier a black-box gatekeeper.

The Python/TypeScript parity goal is especially valuable if the evidence format stays identical across SDKs. Cross-language agents are becoming normal fast.

[nagasatish007]

This is exactly the right framing. Let me map your checklist to how v1.3 handles each:

Decision record completeness

Your seven fields map directly to the TEEC (Typed Evidence & Evidence Contract) envelope:

Your field	TEEC field	Status
What identity/NHI initiated	subject (agent_id, owner, capability_scope)	v1.3 Req 2
What agent/run/turn produced it	correlation_id (links to full trace)	v1.2+
What tool/side effect was requested	action (type, target, parameters)	v1.2+
What data source labels influenced	provenance (source_class, trust_tier, lineage)	v1.3 Req 9.8
Which policy pack and version evaluated	policy_version + policy_pack_id + rule_id	v1.2+
Whether result was allow/deny/approve/quarantine/observe	decision.action + decision.mode (ENFORCE/MONITOR/REPORT_ONLY)	v1.2+
What proof/evidence artifact was emitted	proof (Merkle leaf hash, chain position, anchor reference)	v1.3 Req 7

So yes — every decision record answers all seven questions. The TEEC envelope is the canonical evidence format across both SDKs.

Detection → Policy → Evidence split

This is the core architectural principle. The pipeline is:

Detection (TealGuard, TealClassifier, TealSecrets)
    → produces signals (confidence score, reason labels, matched patterns)
    
Policy (TealEngine)
    → evaluates signals against deterministic rules
    → produces Decision (allow/deny/modify + reason codes)
    
Evidence (TealAudit, TealProof, TealVerify)
    → packages Decision into TEEC envelope
    → hashes into Merkle tree
    → exports to SARIF/JUnit/JSON

Detection never decides. Policy always decides. Evidence always records.

ML classifier as signal, not authority

Exactly right — and this is explicit in the design. TealClassifier produces:

• confidence score (0.0–1.0)
• reason labels
• ensemble mode determines how the signal is used

In ensemble_union mode: classifier signal OR regex signal triggers policy evaluation. But the policy makes the final decision, not the classifier. If confidence is below threshold, the signal is downgraded to observe-only — no enforcement action.

The classifier is never a black-box gatekeeper. It's a signal source into deterministic policy.

Cross-language evidence parity

The TEEC envelope schema is identical in TypeScript and Python. Same field names, same types, same serialization. A TEEC envelope produced by the Python SDK is byte-for-byte parseable by the TypeScript Verification SDK (and vice versa). This is tested as a cross-language property in CI.

---

Your feedback validates the architecture. The detection/policy/evidence split is the thing that makes "deterministic governance" actually mean something — rather than just being a label on a classifier.

Appreciate the detailed review. If you want to dig into any specific module's evidence format, happy to share the schema.