[Idea]: Integration Exploration: TealTiger × OWASP Agent Memory Guard

[nagasatish007]

Your Idea

Following a conversation with @vgudur-dev(OWASP Agent Memory Guard maintainer), we're exploring how TealTiger and Agent Memory Guard can work together as complementary layers in the memory governance stack.

The Natural Split

Layer	Owner	Responsibility
Provenance + Governance	TealTiger (TealMemory)	Track where memory entries came from, assign trust tiers, propagate trust transitively, enforce governance policies
Enforcement Boundary	Agent Memory Guard	Screen every memory read/write for injection, secrets, and tampering at runtime

How They Complement Each Other

Agent Memory Guard is enforcement-first:

• SHA-256 integrity baselines
• Built-in threat detectors (injection, secrets, tampering)
• YAML-defined policy enforcement
• Sub-100μs latency, zero external dependencies
• Currently treats all writes as equally suspect

TealTiger (TealMemory) is provenance-first:

• 5-tier trust classification (direct_user → model_inference → tool_output_internal → tool_output_external → untrusted_document)
• Transitive trust propagation through lineage
• Instruction-likeness scoring for memory entries
• Exfiltration pattern detection
• Governance-level decisions (allow/deny/sanitize based on source + policy)

The Integration Opportunity

Together, the pipeline could look like:

Memory write candidate arrives
    ↓
TealTiger assigns provenance:
  - source_class: tool_output_external
  - trust_tier: untrusted
  - lineage: [web_fetch → model_summary → memory_write]
    ↓
TealTiger evaluates governance policy:
  - "untrusted_document sources require sanitization"
  - Decision: ALLOW with sanitization
    ↓
Agent Memory Guard enforces at the boundary:
  - Integrity hash computed
  - Injection patterns scanned
  - Secrets detected and blocked
  - Entry written (or rejected)
    ↓
Evidence produced:
  - TealTiger TEEC envelope (provenance, policy, decision)
  - Agent Memory Guard integrity record (hash, scan result)

Questions to Explore

1. Interface contract — What data does Agent Memory Guard need from TealTiger's provenance layer? (source_class? trust_tier? full lineage?)
2. Decision flow — Should TealTiger's governance decision (allow/deny/sanitize) feed into Agent Memory Guard's enforcement, or should they evaluate independently?
3. Evidence merging — Can we produce a unified evidence record that combines provenance (TealTiger) + integrity (Agent Memory Guard)?
4. OWASP alignment — Agent Memory Guard is the ASI06 reference implementation. Could TealTiger's provenance layer become a reference for the upstream trust-classification problem?
5. Technical format — What's the best integration point? Middleware chain? Event hooks? Shared context object?

Reference

• OWASP Agent Memory Guard
• TealTiger Memory Governance (v1.3 spec) — see Requirement 9.3–9.8
• OWASP Top 10 for Agentic Applications — ASI06: Memory Poisoning

Next Steps

• Technical discussion here (async)
• Optional sync call to align on interface contract
• Goal: reference integration or joint technical post

cc @vaishnavigudur — looking forward to exploring this together.

Category

New Feature

What problem does this solve?

No response

Potential Impact

No response

Implementation Thoughts

No response

Examples or References

No response

[vgudur-dev]

Hi @nagasatish007 — this is exactly the right framing. The two-layer split (provenance + governance in TealTiger, enforcement boundary in Agent Memory Guard) maps cleanly to how the OWASP ASI06 spec separates the classification problem from the enforcement problem.

Let me address your five questions directly:

1. Interface contract — what does Agent Memory Guard need from TealTiger?

The minimum useful handoff is: source_class + trust_tier. Agent Memory Guard currently treats all writes as equally suspect (conservative default), but with TealTiger's provenance context it can apply tiered scanning thresholds:

from agent_memory_guard import MemoryGuard, ScanContext

guard = MemoryGuard()

# TealTiger provides provenance context
context = ScanContext(
    source_class=tealtiger_entry.source_class,   # e.g. "tool_output_external"
    trust_tier=tealtiger_entry.trust_tier,        # e.g. 2 (untrusted)
    lineage=tealtiger_entry.lineage               # optional, for audit trail
)

result = guard.scan(content, context=context)

This allows Agent Memory Guard to apply stricter injection detection thresholds for untrusted_document sources vs. direct_user inputs.

2. Decision flow — independent or sequential?

I'd suggest sequential with veto: TealTiger evaluates governance policy first (allow/deny/sanitize), and if TealTiger allows, Agent Memory Guard enforces at the boundary. Either layer can block independently. This avoids coupling the two systems while still allowing TealTiger's richer provenance context to inform Agent Memory Guard's scan sensitivity.

3. Evidence merging — unified record?

Yes — a shared evidence envelope would be valuable for audit trails and OWASP AISVS C10 compliance. Proposed structure:

{
  "timestamp": "2026-05-25T00:00:00Z",
  "content_hash": "sha256:...",
  "tealtiger": {
    "source_class": "tool_output_external",
    "trust_tier": 2,
    "governance_decision": "ALLOW_WITH_SANITIZATION",
    "lineage": ["web_fetch", "model_summary"]
  },
  "agent_memory_guard": {
    "scan_result": "CLEAN",
    "threat_types_checked": ["injection", "secrets", "tampering"],
    "integrity_hash": "sha256:..."
  },
  "final_decision": "WRITTEN"
}

4. OWASP alignment

Agent Memory Guard is the ASI06 reference implementation. TealTiger's provenance layer would be a strong candidate for the upstream trust-classification component — this could be proposed to the OWASP Agentic AI working group as a reference architecture for the full ASI06 defense stack.

5. Technical format

Middleware chain is the cleanest integration point — it preserves both systems' independence while allowing the provenance context to flow through. A shared context object (as in the code above) passed through the chain would work well.

Happy to draft a reference integration PR against both repos and a joint technical post. What's the best way to coordinate — async here, or a sync call?

[nagasatish007]

@vgudur-dev — excellent response. You've answered all five questions with concrete, implementable proposals. Let's move forward.

I've drafted the full integration architecture on our side. Here's the summary and action plan:

---

✅ We're aligned on

1. Interface contract
source_class + trust_tier (required), lineage (optional). We'll formalize this as the Memory Governance Context Contract v1 with JSON schema validation and fail-closed semantics.

2. Sequential + Veto model
TealTiger evaluates governance first → if DENY, short-circuit. If ALLOW/SANITIZE → pass to Agent Memory Guard for enforcement. Either layer can block independently.

3. Unified evidence envelope
TEEC v2.1 extension with namespaced blocks:

• tealtiger → provenance + decision
• agent_memory_guard → scan + integrity
• final_decision → derived deterministically

4. OWASP alignment

• TealTiger = provenance/governance (upstream classification)
• Agent Memory Guard = enforcement boundary (ASI06 reference)
• Together = full ASI06 defense stack

5. Middleware chain
Loose coupling, shared context object, no tight dependencies.

---

🏗️ Implementation Plan

We'll host the integration PR on the TealTiger repo (Python SDK side).

PR structure:

integrations/
  agent_memory_guard/
    adapter.py              ← Core adapter (TealTiger context → ScanContext)
    context_contract.py     ← Contract validation (fail-closed)
    evidence_merger.py      ← Unified TEEC receipt generation
    example.py              ← End-to-end pipeline demo
    test_integration.py     ← CI-testable scenarios (no infra)
    README.md               ← Architecture + usage + output examples

Dependency model:

pip install tealtiger[agent-memory-guard]

Core TealTiger stays lightweight — integration is opt-in.

---

📋 What we need from you

Three questions before we start the PR:

#	Question	Why we need it
1	Does Agent Memory Guard's ScanContext accept source_class, trust_tier, and lineage today?	Determines if we need an upstream change
2	What does guard.scan() return? (fields/shape)	We need to merge it into the unified evidence envelope
3	What's the PyPI package name and import path?	For the adapter's dependency declaration

---

🚀 Next Steps

Step	Owner	Timeline
Confirm ScanContext interface + scan result shape	@vgudur-dev	This week
Create GitHub issue on TealTiger for the integration	@nagasatish007	After confirmation
Implement adapter + tests + docs (PR on TealTiger)	Either/both	1–2 weeks
Joint technical post: "Full ASI06 Defense Stack"	Both	After PR merges
Propose reference architecture to OWASP Agentic AI WG	Both	After post

---

📐 TEEC Evidence Model (preview)

We're evolving TEEC into stable core + namespaced extensions:

{
  "timestamp": "2026-05-25T00:00:00Z",
  "request_id": "req-123",
  "agent_id": "agent-1",
  "content_hash": "sha256:...",
  "tealtiger": {
    "source_class": "tool_output_external",
    "trust_tier": 2,
    "governance_decision": "ALLOW_WITH_SANITIZATION",
    "lineage": ["web_fetch", "model_summary"]
  },
  "agent_memory_guard": {
    "scan_result": "CLEAN",
    "threat_types_checked": ["injection", "secrets", "tampering"],
    "integrity_hash": "sha256:..."
  },
  "final_decision": "WRITTEN"
}

Each integration gets its own namespace. Core fields are stable. Extensions are optional.

---

Happy to do a quick sync call if useful, or we can drive this fully async. Let me know on the 3 questions above and we'll create the issue + start the PR.

Looking forward to building this together. 🐯🛡️

[vgudur-dev]

@nagasatish007 — thanks for the detailed writeup, the architecture thinking is solid.
I'd rather not commit to a ScanContext provenance interface right now. The project is Alpha and I don't want to lock the API around one downstream integration before the design has stabilized. That's not the right order of operations.
Happy to do the joint post based on the conceptual architecture. That doesn't require any code changes on either side and is probably the higher-value output anyway.

[nagasatish007]

@vgudur-dev — completely fair. Locking an API around one integration before the design stabilizes would be premature. No pressure on the code side.

Let's go with the joint post. A conceptual architecture piece is the right first output — it establishes the pattern without coupling either project's API.

Proposed post structure:

The problem: Memory poisoning in multi-agent systems (ASI06)
The two-layer defense model: provenance/governance + enforcement boundary
How the layers interact (sequential + veto, shared context)
Reference architecture diagram
What a unified evidence record looks like (conceptual, not locked to an API)
Where each project fits + what's next
Logistics:

I can draft the TealTiger sections (provenance, governance, TEEC)
You draft the Agent Memory Guard sections (enforcement, integrity, threat detection)
We merge into one post
Publish to: Dev.to, both project blogs, and optionally propose to the OWASP Agentic AI working group as a reference pattern.

Want to coordinate via email or keep it async here? I can start a shared doc if that's easier.

When the Agent Memory Guard API stabilizes, we can revisit the code integration — the architecture won't change, just the concrete interface.

[CleanDev-Fix]

This direction makes sense, especially keeping the first output conceptual instead of locking either project into an API too early.

One thing that may make the joint post more concrete is a small scenario-to-evidence table for ASI06. For example:

Scenario	TealTiger responsibility	Agent Memory Guard responsibility	Evidence produced
External tool output is written to memory	classify source/trust tier, preserve lineage, decide allow/sanitize/deny	scan content at the memory boundary for injection/secrets/tampering	TEEC provenance/decision block + AMG scan/integrity block
Previously stored memory is read back into context	expose provenance and prior decision history	verify integrity and rescan if policy requires	unified record showing original source, hash/integrity status, and read-time decision
Suspicious instruction-like content is detected	record governance reason and policy outcome	block or flag boundary operation	final decision with both governance and enforcement reasons

That would keep the article practical while still avoiding premature interface commitments. The API can change later, but the evidence model and responsibility split would be clear for readers.