📋 RFC: TealTiger v1.4.0 — Zero-Config Adoption, A2A Governance & EU AI Act Compliance

[nagasatish007]

📋 RFC: TealTiger v1.4.0 — What's Coming Next

We're sharing our v1.4 roadmap for community feedback. This is a Request for Comments — we want your input on priorities, missing features, and what matters most for your use case.

Target: Q3 2026
Theme: Zero-Config Adoption, Protocol Governance (MCP + A2A), EU AI Act Compliance

---

🎯 The Big Ideas

1. Zero-Config Entry Point (observe())

One line to get instant visibility into your AI agents — no policies, no configuration:

from tealtiger import observe
client = observe(openai)  # That's it. Cost tracked. Tools logged. PII detected.

Progressive path: Observe → Suggest → Enforce → Govern

2. A2A Protocol Governance (First-to-Market)

Google's A2A protocol is GA with 50+ enterprise partners — but has no built-in security layer. TealTiger v1.4 adds:

• Agent-to-agent message policy enforcement
• Agent Card verification (capability allowlisting)
• Cross-agent delegation governance
• Unified MCP + A2A governance in a single policy DSL

3. MCP Security (In-Process, <5ms)

• Per-identity grants (TealGrant) — scoped access per agent/user
• Tool auto-discovery and catalog (TealCatalog)
• Argument-level policy conditions (regex, range, pattern matching)
• Human approval workflows (TealApproval)
• Pre-built policy packs (Stripe, AWS, GitHub, Postgres, Slack, Supabase)

4. Framework Adapters (≤5 lines)

First-class packages for:

• langchain-tealtiger (P0)
• langgraph-tealtiger (P0)
• crewai-tealtiger (P1)
• autogen-tealtiger (P1)
• llamaindex-tealtiger (P2)

Each works in dual mode: zero-config (observe) or policy-driven (enforce).

5. EU AI Act Runtime Compliance

High-risk obligations activate August 2, 2026. TealTiger v1.4 ships:

• Pre-built EU AI Act policy pack (Articles 8-17 mapped to modules)
• Automated compliance evidence generation
• NIST AI RMF alignment
• tealtiger.compliance.enable('eu-ai-act') — one line

6. TEEC v2.1 — Execution Receipts

Evolved evidence contract with:

• Decision validity, expiry, and supersession
• JCS canonicalization for deterministic hashing
• Receipt invalidation on argument mutation
• REVISE decision route (in addition to ALLOW/DENY/REQUIRE_APPROVAL)
• Action sequence scoring (detect kill chains across multiple actions)

7. NVIDIA Ecosystem Integration

• NeMo Guardrails integration (probabilistic safety + deterministic governance)
• NIM governance adapter (TealNIM)
• TensorRT-accelerated TealClassifier (<2ms GPU inference)

---

🗳️ We Want Your Feedback

1. What's most important to you? Which features would you use first?
2. What's missing? Any governance scenarios we haven't covered?
3. Framework priority? Which adapter do you need most urgently?
4. A2A governance — are you deploying A2A in production? What governance gaps do you see?
5. EU AI Act — are you affected by the August 2 deadline? What compliance evidence do you need?
6. Policy packs — which MCP servers should we prioritize policy templates for?

---

📐 Architecture Constraints (Non-Negotiable)

All v1.4 features MUST be:

• In-process — no external service dependency
• <5ms overhead — deterministic, no LLM in governance path
• Zero network hop — no proxy, no sidecar required
• Offline capable — works air-gapped

---

🔗 Links

• Current v1.3 release: npm | PyPI
• OWASP Agentic Top 10 coverage: zero-config policy pack
• NVIDIA Inception member
• Contributing: CONTRIBUTING.md

---

How to Contribute to v1.4

• 💬 Comment on this discussion with feedback
• 🐛 Open issues for specific feature requests
• 🔧 Pick up a "good first issue" to start contributing
• 📝 Help write policy packs for MCP servers you use

---

Drop a 👍 on the features you want most, or comment with what's missing.

[CleanDev-Fix]

The v1.4 direction looks strong, especially the Observe -> Suggest -> Enforce -> Govern path.

A few implementation-oriented thoughts from the contributor side:

1. For observe(), I would make the first receipt useful even before policies exist. The minimum high-value fields seem to be: provider/model, tool name, caller identity if available, argument hash, decision mode (OBSERVE), cost/latency, and a correlation id that can later join to TEEC evidence.

2. For MCP + A2A policy packs, I would prioritize GitHub, Slack, Postgres, and AWS first. Those cover the main risk classes: code/repo mutation, external messaging, data access, and cloud-side effects.

3. For TEEC v2.1, the REVISE route is important. It would be useful to distinguish “blocked” from “safe transformed request,” especially for agents where the best outcome is not denial but narrowing arguments or requiring a smaller scoped action.

4. For framework adapters, I would vote LangGraph first after LangChain. The graph/state model makes governance receipts more valuable because teams need to understand not just one tool call, but how a sequence of agent decisions led to a side effect.

The feature I would most want as a contributor is a small “policy pack authoring guide” with one complete MCP server example: tool catalog, grants, argument-level conditions, approval route, and expected TEEC receipt.

[nagasatish007]

Great feedback @CleanDev-Fix — all four points align well with where we're heading. A few updates and responses:

1. observe() first receipt — Agreed completely. The minimum receipt from observe() will include: provider, model, tool name, caller identity (auto-generated agent ID if not set), params_hash (SHA-256 of JCS-canonicalized args), mode (OBSERVE), estimated cost, latency_ms, PII findings (if any), and a correlation_id. This gives immediate value even without any policy config. The receipt feeds directly into npx tealtiger dashboard for live visibility.

2. Policy pack priority — We're aligning with your recommendation: GitHub, Slack, Postgres, AWS, Stripe, Supabase as the initial six. They cover the four risk classes you identified (code mutation, external messaging, data access, cloud side-effects). Each pack ships with pre-classified tools: DESTRUCTIVE / MUTATING / READ with deny-by-default for destructive.

3. REVISE route — Spot on distinction. We're implementing REVISE as "the proposed action is not allowed as-is, but a modified version might be." It includes revision_guidance telling the agent what to change (e.g., "reduce amount below $1000", "remove PII from payload"). This is distinct from DENY (stop entirely) and REQUIRE_APPROVAL (human decides). Max revision attempts is configurable (default: 3), after which it falls to DENY. Each attempt gets its own TEEC receipt for full audit chain.

4. LangGraph priority — Also agreed. LangGraph's governance_checkpoint() node is P0 alongside LangChain. The graph/state model means we can show: "this sequence of 4 tool calls across 3 nodes led to this budget threshold being crossed" — which is exactly the kind of context that compliance teams need but currently can't get.

On the policy pack authoring guide — this is a great suggestion. We'll ship a docs/guides/policy-pack-authoring.md with one complete worked example: MCP server tool catalog → TealGrant definitions → argument-level conditions → approval routes → expected TEEC receipt output. Will make this a v1.4 documentation requirement.

One timeline update: The EU AI Act high-risk deadline has been extended to December 2, 2027 via the EU Digital Omnibus (provisional deal May 2026). So the compliance features are still P1 for v1.4 but no longer a crisis deadline — gives enterprises a compliance runway rather than last-minute scramble.

Also, A2A governance has been moved to P2 (ships if time allows, won't block release) since A2A production adoption is still early. MCP governance and framework adapters take priority.

Thanks for the thoughtful input — this is exactly the kind of implementation-oriented feedback that shapes the final design. 🐯

[CleanDev-Fix]

Thanks for the detailed response. That priority order makes sense to me: useful zero-config receipts first, MCP policy packs and framework adapters next, and A2A as a later release item unless adoption pressure changes.

For the policy-pack authoring guide, the piece I would find most useful is a tiny offline fixture suite alongside the written example. Something like:

1. one MCP tool catalog fixture,
2. one TealGrant fixture,
3. one allow case,
4. one require-approval case,
5. one revise case,
6. one destructive-deny case,
7. expected TEEC receipt snapshots for each case.

That would make the guide useful both as documentation and as a contributor test harness. It also keeps the examples aligned with the in-process/offline constraints from the RFC.

I would be happy to help with that guide or fixture set once the v1.4 docs/issues are split out.

[nagasatish007]

That fixture-suite idea is excellent @CleanDev-Fix — exactly the kind of "docs that double as tests" approach we want.

We're building v1.4 in a hybrid model: core engine work (observe(), TEEC v2.1, adapter architecture) is internal, but docs, policy packs, and test fixtures are great contributor surface area. This guide fits squarely in the contributor lane.

Here's the structure I'm thinking:

docs/guides/policy-pack-authoring/
├── README.md # The written guide
├── fixtures/
│ ├── tool-catalog.json # MCP tool catalog (5 tools, mixed risk)
│ ├── grants.json # TealGrant definitions
│ ├── policy.yaml # Argument-level conditions + approval routes
│ └── cases/
│ ├── allow.json # Input + expected TEEC receipt
│ ├── require-approval.json
│ ├── revise.json
│ ├── deny-destructive.json
│ └── deny-budget.json
└── run-fixtures.ts # Evaluates all cases offline, compares receipts

I'll create the issue this week with this structure and assign it as "good first issue" for v1.4 contributors. If you want first pass, it's yours.

Appreciate the continued input. 🐯