Pattern: combining AGT policy evaluation with external data quality signals

[SomeshZanwar]

While building a governance layer for data/analytics agent workflows, I ran into a gap that AGT's policy engine doesn't currently cover.

The policy engine answers: Is this agent authorized to perform this action?

In data-heavy workflows, there's a second required check that runs separately: Is the target dataset trustworthy at the time of access?

These two checks typically live in different systems. The policy engine doesn't know what the data quality layer knows. The result is an agent that is fully authorized to query a dataset, but the dataset failed freshness and validation checks that morning. AGT says allowed. The data says don't trust this. Without a shared decision point, the agent proceeds.

I built a prototype to test this pattern:

Layer 0 : Identity: is this agent registered?
Layer 1 : AGT policy: is this agent authorized for this action? Uses PolicyEngine, PolicyRule, AgentContext, ExecutionRequest.
Layer 2 : Data quality: is the target dataset fresh and above the quality threshold right now?

The request is blocked if any layer fails. Every decision: allowed or blocked, and which layer handled it, goes to a unified audit log.

Concrete case this catches:

• analyst-agent-01 is authorized to run database_query
• Target dataset (user_events) failed freshness check: stale by 14h
• Failed tests: not_null_user_id, accepted_values_event_type
• Quality score: 0.72 (below 0.85 minimum)
• AGT policy evaluation: allowed
• Data quality check: blocked

Without the second layer, the agent queries broken data with a clean audit trail.

Working prototype: https://github.com/SomeshZanwar/data-quality-aware-agent-governance

The data quality registry in the prototype is simulated, it mirrors the kind of metadata a dbt-based governance platform exposes at runtime (freshness threshold, quality score, failed test names, dataset owner). A production version would pull from real dbt artifacts or a metadata catalog.

Would an example demonstrating this pattern fit under examples/? Proposed scope: README, a single self-contained Python file using real AGT objects (PolicyEngine, PolicyRule, AgentContext, ExecutionRequest), sample YAML policy, and expected output. No new dependencies to core paths.

Flagging @imran-siddique given the earlier conversation.

[SomeshZanwar]

Quick update on where this went: the two-layer framing that came out of #814 : integrity hash in CTEF, typed evidence artifact at AGT, ended up as a concrete contribution to CTEF v0.3.2. A data-quality scheme is going into the source_version registry in the field-shapes PR (a2aproject/A2A#1786), targeting the May 22 freeze.

The AGT layer is still the part I want to develop further here, specifically whether the typed evidence artifact (freshness_at, quality_profile_id, dataset_owner_did) fits under examples/ as a self-contained pattern alongside the policy engine objects.

[imran-siddique]

Let me know how can we help on this one?

[SomeshZanwar]

Thanks Imran. Here’s what I’m proposing for examples/:

A self-contained pattern showing the two-layer governance check, AGT policy evaluation combined with an external data quality signal, as a single decision point.

Proposed files:

• examples/data-quality-aware-governance/README.md : explains the pattern, when to use it, and how it extends the base AGT policy engine

• examples/data-quality-aware-governance/example.py : working Python using real AGT objects (PolicyEngine, PolicyRule, AgentContext, ExecutionRequest) with a simulated data quality registry returning freshness, quality score, and failed test names

• examples/data-quality-aware-governance/policy.yaml : sample YAML policy defining the data quality thresholds the agent must pass before executing

The example would show a concrete case: an agent authorized to run database_query on user_events, blocked because the dataset failed freshness and validation checks — with both the AGT decision and the data quality check written to a unified audit log.

No new dependencies to core paths. Follows the existing examples/ structure. Happy to open a draft PR once you confirm the scope fits.

[imran-siddique]

Sounds good, please go ahead!

[ElamOlame31]

Related to the pattern you're describing — behavioral signals over time are equally important external data sources. In AgentGate, the behavioral trust dimension (20% of the total score) incorporates request velocity, access pattern anomalies, and cross-session patterns like SENSITIVITY_RAMP. These aren't just policy inputs — they degrade trust dynamically across 24h.

Would AGT's policy evaluator have a hook point for time-series behavioral signals like these?

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

https://www.tryagentgate.com/