Runtime governance guardrails

[imran-siddique]

Summary

We've built a governance integration for the OpenAI Agents SDK in the Agent Governance Toolkit (MIT, 6,100+ tests). The adapter lives at packages/agentmesh-integrations/openai-agents-trust/.

What it provides (distinct from prompt-level guardrails)

Capability	Description
Policy enforcement	Deterministic allow/deny rules before tool execution (<0.1ms)
Trust guardrails	Cryptographic agent identity with trust scoring (0–1000)
Governance hooks	Pre/post execution hooks for policy and audit
Audit logging	Hash-chained audit trail for every agent action

This is complementary to the SDK's existing guardrails — those focus on prompt/output safety, while this handles runtime governance (which tools can be called, by which agents, with what permissions).

Integration approach

The adapter wraps the Agent class with governance middleware, intercepting tool calls for policy evaluation. No changes to the SDK needed.

pip install openai-agents-trust

Why this matters

• Enterprise deployment — runtime policy enforcement and audit trails are prerequisites for production
• OWASP coverage — addresses OWASP Agentic Top 10 risks at the runtime layer
• Handoff governance — trust-gated agent handoffs with accountability

Open question

Would there be interest in listing this as a community integration or documenting a governance middleware pattern?

[seratch]

Thanks for sharing this integration! We don't yet have document sections highlighting community integrations except for tracing providers, but I'll update you when we add something for it in the future.

[Jairooh]

This is a common challenge with agent-based systems. Traditional logging misses the autonomous decision-making that makes agents different from regular API calls.

We've been working on AgentShield (https://useagentshield.com) which provides runtime observability specifically for AI agents — tracing every action, tool call, and decision point with risk scoring. It integrates via callbacks/middleware so it doesn't require changes to your agent logic.

Happy to help if this is related to what you're running into.

[pshkv]

Great to see this published — the Agent Governance Toolkit fills a real gap in the OpenAI Agents SDK ecosystem.

We've been building SINT Protocol as a formal security and governance layer for physical AI agents (robot control, industrial systems, actuators), and the architectures have significant overlap. A few things worth cross-referencing:

Where SINT adds to what AGT provides:

1. Physical constraint enforcement in tokens — SINT's capability tokens carry physical-world safety invariants (maxVelocityMps, maxForceNewtons, geofence) as first-class protocol fields, enforced at the gateway before any tool reaches its target. This is the missing piece for AGT when the tools being governed control physical systems, not just APIs.

2. Formal DFA for request lifecycle — SINT models every request as a deterministic finite automaton (IDLE → PENDING → POLICY_EVAL → ESCALATING → ACTING → COMMITTING → COMPLETED). The "escalating" path is structurally enforced — physical actuations are only reachable via the ACTING state, which requires a valid token + passed policy evaluation. This gives a formal correctness guarantee that audit hooks alone can't provide.

3. W3C DID identity instead of trust scores — AGT uses 0–1000 trust scores (probabilistic). SINT uses did:key:z6Mk... Ed25519 identity (cryptographic). Both are useful at different layers — scores for behavior prediction, DIDs for identity binding.

What AGT provides that SINT doesn't have yet:

• Python ecosystem integration
• Trust score accumulation from behavioral history
• The multi-framework adapters (LangGraph, etc.)

These look complementary rather than competing. The SINT gateway could use AGT's trust scores as the Δ_trust factor in tier assignment — Δ_trust(r) = +1 if score < threshold. Happy to discuss a joint integration story if there's interest.

Reference implementation: https://github.com/pshkv/sint-protocol (TypeScript, Apache 2.0, 815+ tests)

[JohnnyTarrr]

Solid proposal. On the output verification piece specifically — making sure agents aren't acting on hallucinated information — VeroQ Shield provides claim-level verification as middleware.

from veroq import shield then result = shield(agent_output) before any tool call. Returns confidence scores + corrections. CachedShield variant with local LRU for latency-sensitive agent loops.

Could work as a pre-tool-call check alongside the policy enforcement you're describing. Two layers: policy says "allowed", verification says "accurate".

pip install veroq

[imran-siddique]

Thanks @pshkv and @JohnnyTarrr for the interest. Quick update on what's shipped since the original proposal:

We now have a working integration at \packages/agentmesh-integrations/openai-agents-agentmesh/\ and \openai-agents-trust/\ — published on PyPI as \openai_agents_agentmesh. Plus a comprehensive 9-scenario demo at \�xamples/openai-agents-governed/\ covering tool governance, prompt injection defense, multi-agent trust, and output verification.

@pshkv — SINT Protocol for physical AI agents is an interesting complement. Our current focus is software agent governance, but the policy enforcement patterns (especially the kill switch and real-time SLO monitoring in agent-sre) translate well to safety-critical systems. Happy to explore if there's a common interface.

@JohnnyTarrr — output verification as a trust signal maps well to our content governance module (ContentQualityEvaluator). A VeroQ confidence score could feed directly into the policy evaluation context. If you're interested in building a lightweight adapter, check the integration template at \packages/agentmesh-integrations/template-agentmesh/.

[JohnnyTarrr]

@imran-siddique nice — will check out the integration template. A VeroQ adapter that feeds Shield confidence scores into ContentQualityEvaluator makes sense as a clean integration point.

The mapping would be straightforward:

• Shield trust_score (0-1) → policy evaluation context score
• Per-claim verdicts → granular content quality signals
• Verification receipts → audit trail for the governance layer

Will take a look at packages/agentmesh-integrations/template-agentmesh/ and put together a lightweight veroq-agentmesh adapter. Should be a clean fit since Shield already returns structured JSON that maps to evaluation contexts.

Is there a test harness for the 9-scenario demo I can run the adapter against?

[JohnnyTarrr]

Built the adapter: veroq-ai/veroq-agentmesh

Followed the template-agentmesh structure. Two components:

• ShieldEvaluator — runs Shield on agent output, maps to AgentMesh content quality dimensions (accuracy, completeness, consistency). Generates audit entries with verification receipts.
• ShieldActionGuard — gates actions with trust adjustment: effective_score = base_trust * shield_trust_score. An agent with trust 800 producing output with 0.5 accuracy gets effective 400 — below most thresholds.

Mapping:

Shield Output	AgentMesh Target
trust_score (0-1)	accuracy dimension / policy context trust_score (×1000)
verifiable / total claims	completeness dimension
1 − contradicted / total	consistency dimension
Per-claim receipt IDs	Audit trail entries

Works with ContentQualityEvaluator — evaluate_to_quality_scores() returns a dict that maps directly to ContentDimension enum values.

from veroq_agentmesh import ShieldEvaluator, ShieldActionGuard

evaluator = ShieldEvaluator(api_key="vq_...")
report = evaluator.evaluate(agent_output, agent_id="did:mesh:writer")

# Feed into policy evaluation
ctx = report.to_policy_context()
# {'trust_score': 730, 'claims_contradicted': 1, 'receipt_ids': [...]}

# Or gate actions directly
guard = ShieldActionGuard(
    min_trust_score=500,
    sensitive_actions={"publish": 800},
    shield_evaluator=evaluator,
)
result = guard.check_with_verification("did:mesh:writer", 900, "publish", agent_output)

26 tests, all passing. Zero hard dependency on the toolkit — duck typing throughout, same pattern as the other integrations.

pip install veroq-agentmesh

[jagmarques]

Good to see governance layers for the Agents SDK. One gap neither approach covers yet - tamper-evident proof of what happened. The policy evaluation and content checks are valuable but they're only as trustworthy as the storage they write to. Adding a signing step that chains each guardrail evaluation into a hash-linked audit trail would let auditors verify the governance actually ran, not just trust the logs say it did.

[pshkv]

Strong direction. A useful bridge for production adopters is to standardize the handoff from SDK guardrails to operational control planes:

• pre-tool authorization (capability + tier)
• approval suspend/resume for high-risk actions
• immutable execution evidence for post-incident analysis

CTA: if maintainers want, we can submit a reference integration example from sint-ai/sint-protocol showing OpenAI Agents SDK -> policy decision -> approval flow -> evidence ledger, with fail-closed defaults.

Happy to adapt it to your preferred extension API and help teams migrate incrementally.

[pshkv]

Follow-through from our side: we shipped a reference Python adapter for runtime governance integration.\n\nPR: https://github.com/sint-ai/sint-protocol/pull/112\n\nIncludes:\n- pre-tool-call authorization wrapper\n- typed deny/escalate/timeout/approval-denied outcomes\n- suspend/resume approval helpers\n- evidence lookup helper + fail-closed profile template + migration guide\n\nHappy to co-adapt this to native extension points in openai-agents-python if maintainers want a focused interop PR.

[pshkv]

Great discussion. The biggest adoption unlock we’ve seen is making guardrails composable with existing agent code, not requiring rewrites.

A practical integration seam:

• pre-tool-call authorization
• optional suspend/resume approvals for high-consequence actions
• evidence references for post-incident debugging

We shipped a Python reference adapter with typed outcomes and a fail-closed timeout path. Happy to align it with maintainers’ preferred extension hooks and reduce it to a minimal interop example if that helps.