Repository navigation
[Feature] Reference adapter: external open detection engine (ATR) via ACS custom/annotator slots #3018
Description
Activity
🔴 Contributor Check: HIGH
Check Result Profile HIGH Credential HIGH Overall HIGH Automated check by AGT Contributor Check.
Thanks for the detailed proposal, Adam. This is exactly the kind of example the ACS
custom/annotator extension slots are designed for.Short answers to your two questions:
Where should it live?
examples/— specificallyexamples/acs-atr-annotator/. We keep runtime enforcement examples there alongside the other framework-specific examples. The existingdocs/mappings/atr-agt-mapping.mdcovers the static control alignment; this example covers the behavioral enforcement path, so they sit at different levels and don't conflict.Are
custom/annotator slots the right home? Yes. Acustompolicy type paired with an annotator dispatcher is the correct pattern for a detection engine that runs in-process and produces a verdict. ACS evaluates the annotator output as part of the policy decision, which is what you want for blocking — ATR match →custompolicy → deny.Guidance for the PR:
- The adapter should normalize an ATR
Matchresult into an ACSAnnotatorResult(verdict + reason + optional evidence dict). Keep it thin — the adapter's job is shape translation, not re-implementing ATR logic. - Include a sample policy YAML that uses
custom: atr_annotatorwith a configurable rule-set path. - A
demo.pywith at least one benign and one malicious prompt is sufficient. No real endpoints. - Validate against the ACS runtime before opening the PR (you mentioned this — good instinct).
- Check that
pyatris available on PyPI with a stable release before pinning it as a dependency; if it isn't, stub the import with a clearImportErrormessage like the other optional-dep integrations.
Happy to review once it's up. Tag me when the PR is ready.
- The adapter should normalize an ATR
Package
Agent Control Specification (ACS) / policy-engine
Problem Statement
ACS defines
custompolicy types andannotatorsas extension points so that policy decisions can call out to host-provided dispatchers / classifiers enforced outside the model. There is currently no worked example of plugging an external, open-source detection engine into those slots, so an implementer who wants to enforce an existing rule-based detector at the ACS interception points has no reference to follow.Proposed Solution
A small reference adapter showing Agent Threat Rules (ATR) as an ACS annotator /
customdispatcher. ATR (https://github.com/Agent-Threat-Rule/agent-threat-rules, MIT) is an open detection ruleset for AI-agent threats with a Python engine (pyatr) that runs in-process with no model call. The adapter would normalize ATR matches into the verdict shape ACS expects, so acustom/annotator policy can block or flag a request based on ATR rules at the agent-loop interception points.This is distinct from the existing merged ATR mapping in AGT (#908), which is a static control mapping; this is a runtime/behavioral enforcement example exercising the ACS extension slots.
Alternatives Considered
Keeping ATR purely as a static mapping (already in AGT). That covers documentation/control alignment but not the runtime enforcement path that ACS's custom/annotator slots enable.
Contribution
I would be willing to submit a PR for this (an example/sample), pending your guidance on where it should live and whether the ACS extension slots are the intended home for external detection engines. Flagging that I'd want to validate it against the ACS runtime before opening the PR.