Collaboration: Governance callbacks for ADK agent lifecycle

[imran-siddique]

Hi @klateefa @DeanChensj

We recently moved our agent governance work to microsoft/agent-governance-toolkit under the Microsoft org, and wanted to restart the conversation around ADK integration with a cleaner scope.

The problem we're focused on: As ADK agents get deployed in production, teams need runtime governance - policy checks on tool usage, audit trails for compliance, capability restrictions based on context. Today this requires custom per-agent implementation.

What we'd like to explore with the ADK team:

1. Before/after callbacks on tool execution - Is there an established hook point where governance checks could run before a tool is invoked and after results return? This would enable policy-based tool filtering without modifying agent logic.

2. Sub-agent delegation governance - When an agent delegates to a sub-agent, is there a callback or event where trust/permission checks could be inserted?

3. Structured audit events - Does ADK emit structured lifecycle events (agent started, tool called, delegation happened) that a governance layer could subscribe to?

We're not proposing any specific implementation yet - we want to understand ADK's extension model first and design something that feels native. If there are existing patterns for cross-cutting concerns in ADK, we'd love pointers.

Repo: microsoft/agent-governance-toolkit
Install: pip install ai-agent-compliance

[aeoess]

Following this with interest. We commented on @imran-siddique's related work on microsoft/agent-governance-toolkit (#140) and A2A (#1604).

For ADK governance callbacks specifically, the Agent Passport System (v1.13.0, shipped today) provides the cryptographic primitives that could power those hooks:

• Before-action callback: Our intent declaration requires agents to declare what they're about to do. A policy engine evaluates against delegation scope + values floor. Returns APPROVE or DENY with a signed PolicyDecision.
• After-action callback: Every execution generates a signed ActionReceipt - tamper-proof audit trail with beneficiary attribution.
• Tool-use governance: ProxyGateway (new in v1.12.0) validates identity, delegation scope, and reputation tier before any tool invocation reaches the system.
• Capability restrictions: Delegation chains enforce monotonic narrowing - agents can only operate within the authority explicitly granted to them.

The before/after callback pattern maps 1:1 to our 3-signature chain (intent → policy → receipt). Happy to explore how this could integrate with ADK's lifecycle hooks.

534 tests, 61 MCP tools, 16 modules.
https://github.com/aeoess/agent-passport-system

[klateefa]

@imran-siddique Thank you for submitting this feature request. It’s currently under review by our team, and I’ll keep you posted on any updates. We appreciate your input!

[imran-siddique]

Thanks @klateefa — appreciate the quick triage.

We'll keep an eye on the capabilities API (#4303) — once that ships, the natural integration point is wrapping capability checks with governance policy evaluation. Happy to be early testers when it's ready.

In the meantime, if it's helpful we can put together a short design doc showing the specific callback points we'd need (pre-tool, post-tool, delegation) and how they map to ADK's current agent lifecycle. That way the team can evaluate whether governance hooks fit naturally into the capabilities API or need a separate extension point.

[razashariff]

MCPS (MCP Secure) provides the cryptographic foundation for governance callbacks — every MCP tool call is ECDSA P-256 signed with nonce + timestamp + agent passport binding. A governance callback can verify the signature to cryptographically prove which agent made the call, when, and that the request wasn't tampered with. Agent passports carry trust levels (L0-L4), capabilities, and expiration — all verifiable at the callback layer. Published as an IETF Internet-Draft, 180 security tests, zero dependencies. github.com/razashariff/mcps | Live demo

[aeoess]

@razasharif The governance callback pattern is interesting. Intercepting at the MCP tool call boundary is the right enforcement point -- we call this the "reference monitor" position.

We ended up splitting our policy engine into a deterministic gate (scope, signature, revocation -- hard block) and an advisory path (deception, proportionality -- reputation consequences). The reason: putting an LLM evaluator inside a cryptographic signing chain creates a non-deterministic attestation problem.

Does MCPS hit the same issue? If governance callbacks involve any LLM-based policy evaluation, how do you handle non-determinism in the signed attestation?

[sunilp]

@imran-siddique @klateefa — I'd like to contribute to this discussion from the protocol and governance layer perspective.

I maintain an AI Governance Framework focused on GenAI/LLM systems, and have published research on agent trust protocols — specifically LDP (Lightweight Delegation Protocol) which addresses provenance, delegation chains, and tamper-evident audit trails for multi-agent systems, and DCI (Deliberative Collective Intelligence) for structured multi-agent reasoning. I also have a merged A2A contribution.

On the three asks — ADK already has most of the plumbing

ADK's BasePlugin system provides 12 callback hooks (before/after for agent, model, and tool — plus error handlers). A governance plugin could enforce policies at each lifecycle point without modifying agent logic. The key question is whether the current plugin semantics (first non-None return short-circuits) are sufficient for governance, or whether we need a dedicated governance pipeline that always runs — audit logging shouldn't be skippable by an earlier plugin returning a value.

Concrete proposal — a GovernancePlugin pattern

1. Pre-tool policy gate (before_tool_callback): Evaluate tool name + args against a policy engine. Return a denial response to block, or None to allow. This maps to LDP's intent declaration → policy evaluation → signed decision chain.

2. Post-tool audit receipt (after_tool_callback): Emit a structured audit event (tool, args, result hash, timestamp, agent identity). In LDP, this is the ActionReceipt — a tamper-evident record of what happened.

3. Delegation governance (before_agent_callback on sub-agents): When a parent delegates to a sub-agent, validate the delegation scope. LDP enforces monotonic narrowing — sub-agents can only operate within authority explicitly granted by the parent.

4. Structured audit events: ADK's telemetry module already emits OpenTelemetry spans. A governance layer could attach policy decisions and audit receipts as span attributes, making them queryable via existing OTel infrastructure.

What's missing in ADK today

• No guaranteed execution for governance callbacks — the plugin short-circuit semantics mean a plugin returning non-None bypasses all subsequent plugins AND agent callbacks. Governance/audit hooks need a "mandatory" tier that always runs.
• No structured PolicyDecision or AuditEvent schema — today you'd need to define your own. A standard schema would let governance toolkits interoperate.
• No delegation scope model — sub-agent authority isn't explicitly constrained. Adding a scope/capability model to BaseAgent would enable the monotonic narrowing pattern.
• No policy engine interface — even a simple PolicyEvaluator protocol (with evaluate(tool, args, context) -> PolicyDecision) would provide a standard integration point.

Related work

I've also opened #4895 adding skill-level security support to AgentCardBuilder (for #4479), which covers the A2A card generation side of this. The governance callbacks discussion here covers the runtime enforcement side — they're complementary.

I'd be happy to contribute a design doc or a reference GovernancePlugin implementation that demonstrates these patterns. Would also be interested in collaborating with @imran-siddique on aligning this with the agent-governance-toolkit approach.

[sunilp]

Following up on my comment above — I've built a reference implementation and opened #4897.

It provides a GovernancePlugin that works within the existing BasePlugin system:

• PolicyEvaluator protocol — standard interface for custom policy engines (evaluate_tool_call, evaluate_agent_delegation)
• DelegationScope — monotonic narrowing constraints for sub-agents
• AuditEvent + AuditHandler — structured audit trail with pluggable sinks
• Per-tool policies — blocklists, call limits, audit toggles
• 25 unit tests covering all governance scenarios

This demonstrates what's achievable today within the existing plugin system. The open question from my earlier comment remains: the short-circuit semantics mean governance callbacks can be bypassed by earlier plugins. A "mandatory" callback tier would address this, but that's a framework-level change better discussed separately.

Happy to iterate based on feedback from the team and @imran-siddique.

[razashariff]

In terms of context and end to end, MCPS explicitly avoids this problem by keeping the entire signing chain deterministic.

There is no LLM evaluator in the MCPS attestation path. The signing chain is:

1. Canonical JSON serialisation (RFC 8785 -- deterministic by spec)
2. SHA-256 hash (deterministic)
3. ECDSA P-256 signature (deterministic with RFC 6979)
4. Nonce (cryptographic random, not LLM-generated)
5. Passport identity (pre-issued, static)

Every component produces identical output for identical input. The attestation is fully reproducible and independently verifiable.

Your split between a deterministic gate and an advisory path is the right architecture. In MCPS terms: the deterministic gate maps to our protocol layer (signing, nonce, tool hash-pinning). The advisory path would sit above it -- a behavioural layer (heuristics, anomaly detection) that can flag but doesn't participate in the cryptographic chain.

If an LLM-based policy evaluator needs to influence the decision, it should produce a PASS/FAIL before the signing step -- not inside it. The signed attestation covers "this request was approved and forwarded" not "this request was evaluated by an LLM that said X."

IETF draft: https://datatracker.ietf.org/doc/draft-sharif-mcps-secure-mcp/