Governance/security hooks for multi-agent tool execution

[Naga Satish Chilakamarti (nagasatish007)]

Context

When deploying AutoGen multi-agent workflows in production, teams need governance controls around tool execution:

• Which tools each agent is authorized to use
• Cost tracking per agent (not just per conversation)
• Audit trails linking tool calls to specific agents
• Kill switches for runaway agents
• Prompt injection detection on inter-agent messages

Question

What's the recommended extension point for adding pre/post execution governance in AutoGen?

I see a few possible approaches:

1. Custom ConversableAgent subclass wrapping generate_reply
2. A hook in the tool/function execution path (before execute_function runs)
3. A message filter/interceptor between agents

What I'm building

I maintain TealTiger, an open-source governance SDK (Apache 2.0) that provides:

• Deterministic policy evaluation (no LLM in the governance path)
• Per-agent cost tracking and budget enforcement
• Tool allowlisting with scope enforcement
• Cryptographic audit trail (Merkle + RFC 3161 timestamping)
• OWASP Agentic Top 10 coverage

We've built integrations for CrewAI and LangChain, and I'd like to build one for AutoGen — but want to use the cleanest hook point rather than fighting the architecture.

Specific questions

1. Is there a pre-execution hook for tool/function calls that can block execution?
2. Can message passing between agents be intercepted without subclassing?
3. Is there a preferred pattern for adding cross-cutting concerns (logging, auth, governance) to AutoGen workflows?

Happy to share our CrewAI integration as a reference for what the end result looks like:
https://github.com/agentguard-ai/tealtiger/tree/main/examples/crewai-governance

Would love guidance from maintainers or community members who've solved similar problems.

[Michael 'Mike' K. Saleme (msaleme)]

Great framing. We've solved similar boundary-interception problems across agent frameworks, and the pattern that holds up best is: treat governance as an execution-boundary interceptor, not an agent decorator.

In practice, that means three layers:

1. Pre-execution hook at the tool layer — intercept after the agent decides to call a tool but before execution. This is where deterministic policy evaluation belongs (no LLM in the guard path). The hook receives resolved tool name, arguments, and calling agent identity, and returns ALLOW / BLOCK / ESCALATE.

2. Message interceptor between agents — a lightweight envelope wrapper that adds provenance metadata (sender agent ID, turn ID, policy version) without subclassing ConversableAgent. AutoGen's message passing is already event-driven; tapping into GroupChat's speaker_selection_method or adding a register_reply interceptor gives you cross-cutting observability without fighting the architecture.

3. Post-execution receipt — structured audit output that binds the tool call, the policy decision, and the actual result. For compliance use cases, this is the artifact that matters.

One specific AutoGen pattern that works well: subclass ConversableAgent to override generate_reply for the audit layer, but keep the actual governance decision in a separate ToolGuard object that receives (agent_id, tool_name, args) and returns a verdict. That separation keeps governance logic framework-agnostic and testable.

We've implemented a similar architecture with deterministic guards, per-call audit trails, and framework adapters for CrewAI, LangChain, and AutoGen. If a reference integration would help: https://github.com/msaleme/red-team-blue-team-agent-fabric

[Naga Satish Chilakamarti (nagasatish007)]

Thanks Michael 'Mike' K. Saleme (@msaleme) — really helpful. The register_reply interceptor pattern is exactly what I was looking for. The separation between ToolGuard (verdict) and the agent subclass (audit) makes sense — that's how we've structured it in our LangChain integration too.

I'll build the AutoGen adapter using this pattern and share it back here when it's ready.

[Naga Satish Chilakamarti (nagasatish007)]

Also checked out your Agent Security Harness — impressive test coverage (470 tests across MCP/A2A/L402). Our projects are complementary: you attack, we defend. Would be interesting to run your test suite against TealTiger-protected agents as a benchmark. Open to collaborating on that?

[Elam Olame Mugabo (ElamOlame31)]

In AgentGate we implemented this as a PDP layer — every tool call intercepted before execution, scored across 4 dimensions, then PERMIT / ESCALATE / DENY. For LangGraph: one line to replace ToolNode with AgentGateToolNode. The governance decision is sealed before execution fires — not wrapped around it afterward.

https://github.com/ElamOlame31/agentgate-public

https://www.tryagentgate.com/

[AlgoVoi (Christopher Hopley) (chopmob-cloud)]

The pattern that holds in production is exactly what Michael 'Mike' K. Saleme (@msaleme) described: governance at the execution boundary, not in an agent decorator. Two primitives that make it durable:

Pre-execution gate: action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp_ms})) is a content-addressed handle for the exact tool call payload at the moment it crystallises. A compliance receipt (ALLOW / REFER / DENY) is issued against that hash before execution fires. Any argument mutation between the governance decision and execution invalidates the receipt, so the guard cannot be bypassed by modifying the call after the check. The three-state shape (ALLOW / REFER / DENY) maps directly onto the PERMIT / ESCALATE / DENY pattern Elam Olame Mugabo (@ElamOlame31) described.

Audit trail: every execution outcome is written into a hash-chained audit bundle (per-row content_hash, bundle HMAC, B2 Object Lock COMPLIANCE). Standalone verifier at verify.algovoi.co.uk. The action_ref key links the pre-execution receipt to the post-execution record, making one continuous chain rather than two separate logs.

Specified in §4 of draft-hopley-x402-canonicalisation-jcs-v1. Package: algovoi-substrate on PyPI/npm, Apache 2.0.

AlgoVoi (chopmob-cloud) - chopmob@gmail.com - Acquisition enquiries: https://docs.algovoi.co.uk/acquisition

[Elam Olame Mugabo (ElamOlame31)]

The three-state convergence is real — ALLOW / REFER / DENY and PERMIT / ESCALATE / DENY are solving the same enforcement shape at the execution boundary.

The action_ref + COMPLIANCE lock combination is the right foundation: content-addressed receipt before execution, hash-chained outcome after, action_ref linking both into one continuous chain. That's durable governance evidence.

The layer above it: the receipt chain doesn't know if this ALLOW is the 11th read in 4 minutes. A single receipt is clean. The sequence is the attack. AgentGate scores across the sequence — kill chains emerge from patterns, not from any individual receipt.

Playground shows the sequence detection layer: tryagentgate.com/playground

[AlgoVoi (Christopher Hopley) (chopmob-cloud)]

Thanks Elam Olame Mugabo (@ElamOlame31) -- the endorsement is appreciated, and the sequence point is exactly right.

The layer that sits above the per-receipt chain in our stack is algovoi-composite-trust-query: individual receipts pass but the verdict across the sequence is what the PROVISIONAL and INSUFFICIENT_EVIDENCE states capture, before the aggregated evidence base is sufficient to produce a TRUSTED verdict. Spec: draft-hopley-x402-composite-trust-query. Package on PyPI/npm, Apache 2.0.

AlgoVoi (chopmob-cloud) - chopmob@gmail.com - Acquisition enquiries: https://docs.algovoi.co.uk/acquisition

[vgudur-dev]

Great thread — the execution-boundary interceptor pattern is clearly converging across implementations (TealTiger, AgentGate, red-team-blue-team-agent-fabric). One layer I'd add to the stack: memory integrity as a pre-condition for governance decisions.

The governance hooks discussed here assume the agent's state is trustworthy at decision time. But if an attacker poisons the agent's persistent memory (conversation history, tool output cache, learned preferences), the governance layer makes correct decisions on corrupted inputs — it ALLOWs a tool call that looks legitimate because the memory driving the decision has been tampered with.

This is OWASP ASI06 (Agent Memory Poisoning) — and it's particularly dangerous in multi-agent AutoGen workflows where Agent A's memory output becomes Agent B's context input.

We built Agent Memory Guard to address this layer. It sits below the governance hooks — scanning memory writes before they persist:

from agent_memory_guard import MemoryGuard

guard = MemoryGuard()
# Scan before memory persists — upstream of governance decisions
result = guard.scan(memory_entry)
if result.is_safe:
    memory_store.write(memory_entry)  # governance hooks can now trust this state

Detection covers: prompt injection embedded in memory, sensitive data leakage via memory exfiltration, protected key tampering, and size anomaly attacks. Policy is YAML-configurable per agent.

The integration point for AutoGen specifically: hook into the ConversableAgent's memory/context update path (where conversation history and tool results get persisted), scan before write. That way the governance layer (Naga Satish Chilakamarti (@nagasatish007)'s TealTiger, Elam Olame Mugabo (@ElamOlame31)'s AgentGate) can trust that the state it's evaluating hasn't been poisoned.

Validated against 200+ adversarial payloads in AgentThreatBench — now merged into the UK Government's BEIS inspect_evals framework.

The full stack becomes: AMG (memory integrity) → Governance hooks (execution authorization) → Audit trail (compliance evidence). Each layer is independently testable.

[Mohamed Amine Ferhi (ferhimedamine)]

The PDP layer approach works, but the audit trail dimension needs a persistence layer that outlives the agent session.

From operating 9 agents with tool governance in production:

1. Per-agent tool authorization — solved by namespace-scoped memory. Each agent has a procedural memory namespace containing its authorized tool list, stored at importance 1.0 (never decays). At session start, the agent recalls its authorizations before executing anything. Adding or revoking a tool is a memory update, not a config change.

2. Cost tracking per agent — each tool call stores a memory record with token cost metadata. Querying cost-per-agent is a filtered recall across that agent namespace for tool-call records.

3. Audit trails linking tool calls to agents — every tool call result gets stored with (agent_id, session_id, tool_name, args_hash, timestamp, result_summary). The memory store IS the audit trail — queryable by agent, time range, tool name, or semantic content.

4. Kill switches — importance-weighted decay handles this naturally. Set a "STOP: do not execute tool X" memory at importance 1.0. The agent recalls it before every tool execution check.

The key insight: governance should be stored IN the memory layer, not bolted on as a separate system. One store for memories, decisions, authorizations, and audit trails.

Multi-agent memory with per-agent namespaces: https://github.com/Dakera-AI/dakera-deploy/blob/main/docker/docker-compose.yml

[Joy-0403]

I can see the appeal of keeping everything in one place, but I'd be a bit hesitant to rely on memory recall for a kill switch. If the agent misses the STOP instruction or doesn't follow it, the tool could still run. Seems like you'd still need a hard check right before execution. Is that part of how you've implemented it?

[Alex Carrega (alexcarrega)]

A useful architectural pattern here may be to separate agent reasoning from execution authority.

Instead of embedding governance entirely inside each agent, place a mandatory execution gateway between the agent and any privileged tool. The gateway can perform deterministic pre-execution checks such as:

• agent/tool authorization;
• target and scope validation;
• policy evaluation;
• approval or quorum requirements;
• evidence freshness;
• revocation status;
• blast-radius constraints.

The post-execution side can then validate outcome, record provenance, and trigger rollback or escalation if the observed result differs from the intended state.

For multi-agent systems, I would also make delegation explicit: a child agent should never inherit more authority than its parent, and delegated permissions should be narrower, time-bounded, traceable, and revocable.

This kind of separation is useful because it keeps “what the model wants to do” distinct from “what the system is actually permitted to execute.”