crewai - 💡(How to fix) Fix Docs example: add a runtime trust boundary for crews that read external content and use tools [1 comments, 2 participants]

Feature Area

Integration with external tools

Is your feature request related to a an existing bug? Please link it here.

NA

Describe the solution you'd like

Summary

I’d like to propose a small optional documentation/example addition for CrewAI users who build crews that read external content and call tools.

This is not a request to add a new governance system to CrewAI core.

The narrower use case is:

a crew reads untrusted external content — docs, PDFs, tickets, web pages, retrieved RAG context, or tool outputs — and then continues execution or calls tools.

In that setup, external content can accidentally become part of the control path.

A practical docs/example could show where users can place a runtime trust boundary around:

• crew inputs
• tool calls
• memory-write candidates
• external/retrieved content before it influences execution

Problem

Many agent workflows work well on clean demo data, but become harder to reason about once they ingest real-world content.

The model does not naturally separate:

• trusted instructions
• untrusted content
• intermediate agent context
• tool-facing context

For CrewAI users building crews over external documents or RAG context, it would be useful to have a small example showing how to make that boundary explicit.

Proposed example

A minimal example could show:

1. a CrewAI crew receiving a support ticket / retrieved document as input
2. a tool that should only run after preflight validation
3. a runtime guard installed around crew execution
4. a wrapped tool call
5. a blocked-path example for unsafe instruction-like content

I’m working on an open-source package called Omega Walls that already has a CrewAI adapter.

Example:

from omega.integrations import OmegaCrewAIGuard

guard = OmegaCrewAIGuard(profile="quickstart")

safe_tool = guard.wrap_tool("network_post", network_post_fn)

with guard.install_global_hooks():
    result = crew.kickoff(
        inputs={"topic": "Summarize this support ticket"}
    )

Install:

pip install "omega-walls[integrations]"

The adapter checks:

• model/input flow
• tool calls before execution
• memory-write candidates
• typed blocking behavior

If a tool call is blocked, the integration raises a typed exception instead of letting the workflow continue blindly.

Why this may fit CrewAI docs/examples

CrewAI is often used for workflows where agents consume messy real-world context and coordinate tool usage.

This example would not require CrewAI to depend on Omega Walls.

It could live as one of:

• an external integration example
• a docs recipe
• a cookbook-style example
• a link from a security / reliability / tool-safety section, if such a section exists

Project links

Omega Walls GitHub: https://github.com/synqratech/omega-walls

PyPI: https://pypi.org/project/omega-walls/

Question

Would the CrewAI team be open to an optional PR that adds a small example for this pattern?

If yes, I can prepare a minimal PR that keeps the existing CrewAI behavior unchanged and only demonstrates the integration as an optional pattern.

Describe alternatives you've considered

No response

Additional context

No response

Willingness to Contribute

Yes, I'd be happy to submit a pull request