Question: integration path for Agent Threat Rules detection in crewai/security

[eeee2345]

Hi CrewAI maintainers,

I am Adam Lin, maintainer of Agent Threat Rules (ATR), an open Apache 2.0 detection standard for AI agent threats. ATR currently ships 330 community-maintained rules across ten attack categories: prompt injection, tool poisoning, skill compromise, context exfiltration, agent manipulation, privilege escalation, excessive autonomy, model abuse, model security, and data poisoning. Repo: https://github.com/Agent-Threat-Rule/agent-threat-rules. Microsoft agent-governance-toolkit and Cisco AI Defense skill-scanner reference ATR rules as an upstream source.

I noticed lib/crewai/src/crewai/security/ has fingerprint and security_config in place, with security_config.py listing scoping rules and impersonation and delegation as future work. ATR rules are catalog-driven YAML pattern definitions rather than scope or delegation mechanisms, but they could plug into a hook on the agent or task lifecycle to flag adversarial inputs in user messages, tool outputs, retrieved documents, and inter-agent messages.

Before opening a PR I would like to confirm scope and architecture with you. Open questions follow.

Where should detection hooks attach in the crew lifecycle? Candidate sites: pre-task input scan on Task.execute, pre-tool-call scan on Tool input, post-tool-call scan on Tool output, and inter-agent message scan when delegation is used. The closest existing seam is the GuardrailProvider work hinted at in issue 4877.

What is the preferred dependency posture? ATR rules and the lightweight matcher are pure Python with no heavy native deps. The detection engine could be vendored as a small module under crewai.security.atr, or wired through an optional extra so users opt in with pip install crewai[security].

Is a thin first cut acceptable, scoped to one of the ten ATR categories (for example prompt-injection only, the largest at 109 rules), as proof of fit before broadening? I would aim for under 120 lines of Python plus tests.

Would the maintainers prefer this lives in lib/crewai-tools as a tool integration rather than in lib/crewai core? The crewai-tools/security folder already holds safe_path; an atr_input_scanner could sit alongside.

The companion v0.3 OSCAL catalog at https://github.com/Agent-Threat-Rule/ai-rmf-oscal-catalog under CC0 maps the ATR rule set to NIST AI RMF controls if that helps with the EU AI Act and NIST AI RMF positioning that came up in issue 5360.

Apache 2.0 on the ATR side. Happy to follow whatever direction the maintainers prefer. The llm-generated label is applied per the AI contribution policy in CONTRIBUTING.md.

Thanks,
Adam Lin (adam@agentthreatrule.org)

[Jairooh]

Great question. The lifecycle hooks you've identified (pre-task, pre-tool, post-tool output, inter-agent) are exactly right—pre-execution checks catch issues before damage, while post-execution scanning catches downstream propagation. In production systems, you typically want both: pre-tool-call scanning prevents immediate harm, but post-tool-output scanning catches cases where tool returns are unexpectedly malicious or exfiltrated. On dependency posture: catalog-driven YAML rules are the right abstraction for community contributions and enable the kind of ecosystem you're building. We use a similar pattern at AgentShield for standardizing risk signals across frameworks, and the decoupling from CrewAI internals makes it easier for teams to adopt security detection without tight coupling.

[reallyticsai]

Integrating ATR rules sounds like a solid approach to beef up threat detection in crewAI. From our experience building detection layers in AI workflows, the best lifecycle hooks tend to be close to input ingestion and output emission — so your idea of scanning before Task.execute and after Tool outputs aligns well with production needs. This lets you catch adversarial inputs early and flag suspicious tool results without slowing down core logic.

If GuardrailProvider is meant as a pluggable interception layer, that’s likely the cleanest integration point to avoid scattering detection logic. Regarding dependencies, we usually prefer optional or plugin-based loading of heavy rule sets like ATR to keep the core lightweight. Using a YAML-driven rules engine (like what ATR provides) is great; you might consider wrapping it in an async caching layer to minimize latency impact when scanning messages or documents.

Overall, aiming for modular hooks at these points:

• Pre-Task input validation
• Pre-Tool input scanning
• Post-Tool output analysis
• Inter-agent message inspection (for delegation scenarios)

should give good coverage while maintaining crewAI’s performance and maintainability.

[DreicLabs]

Agree on attaching at pre-task and pre-tool — those hooks definitely beat post-hoc detection.

One thing worth thinking about: catalog-driven YAML rules (ATR's pattern) catch what you've named. The long-tail cases — agent doing something semantically wrong with permitted credentials, no rule matched — need a different layer.

I tested two agents: one with rules in the system prompt, and one with rules running as a separate LLM between the agent and tool execution. The system-prompt version can be talked out of its rules under user pressure. The separate-LLM version can't.

Not against ATR — pattern catalog catches the known, semantic gate catches the novel. Both at the pre-tool hook is the stronger shape: https://www.npmjs.com/package/@contextgate/mcp