CrewAI Agent Governance: How to Add Trust Scores to Your Multi-Agent Crew

A working guide to CrewAI governance in production with OpenBox: a trust score for every agent, four governance decisions, behavioral rules across handoffs, and tamper-evident audit evidence.

What Governance Means for a CrewAI Agent (And Why Testing Is Not Enough)

Governance for a CrewAI agent means enforcing what each agent is allowed to do at runtime and producing signed evidence of every decision, not just checking that the crew produced the right output in a test. Testing proves your crew works on the inputs you chose. Production hands it inputs you did not.

A crew that passes every test can still behave differently in production for reasons unrelated to your code. The model is non-deterministic. The data is live. The tools reach real systems with real consequences. A Researcher that summarized a fixture in development now queries a production database. A Writer that drafted sample copy now emails a customer.

Governance is the layer between the agent decided to do X and X actually happened. OpenBox, an AI agent governance platform, wraps a CrewAI crew so every governed task and tool call is evaluated against policy before it runs, scored over time, and recorded as tamper-evident evidence. Your manager's question about whether the agents behave as intended at scale is a CrewAI governance question. The rest of this guide is the answer.

Installing the OpenBox SDK in Your CrewAI Project

Install the OpenBox CrewAI SDK with pip install openbox-crewai-sdk-python. It requires Python 3.10 or newer and CrewAI 1.14.1 or newer, an OpenAI API key, a reachable OpenBox Core URL, and one OpenBox agent provisioned per governed role.

The SDK is published on PyPI as openbox-crewai-sdk-python and developed in the open on GitHub under the MIT license.

pip install openbox-crewai-sdk-python

# or, with uv

uv add openbox-crewai-sdk-python

One design point matters before you write code. The SDK connects your CrewAI runtime to OpenBox, but trust policy, approvals, guardrails, and the dashboard live on the OpenBox platform, not inside the SDK. The library instruments your crew and talks to OpenBox Core over HTTPS; the decisions come back.

Adding a Trust Score to Each Agent in Your Crew

In OpenBox, every governed CrewAI agent carries its own Trust Score, a 0 to 100 measure calculated as (Risk Profile Score x 40%) + (Behavioral x 35%) + (Alignment x 25%). Each role in your crew, whether Researcher, Writer, or QA, is provisioned and scored separately, so trust is tracked per agent rather than for the crew as one unit.

Give each agent its own identity. When you provision a role in OpenBox you receive three things: a per-agent API key, an agent DID, and a one-time private key used for request signing. You bind them to the agent with an env_prefix, which maps to that role's environment variables. The API key is required for every governed agent. The DID and private key are optional: set them only when you want per-agent AIP request signing, since API-key-based governance works without them.

from openbox import OpenBoxAgent

researcher = OpenBoxAgent(

    role="Researcher",

    goal="Find information",

    # Reads OPENBOX_RESEARCHER_API_KEY / DID / PRIVATE_KEY

    env_prefix="OPENBOX_RESEARCHER",

)

The Trust Score maps to a Trust Tier that decides how much autonomy the agent gets. A higher score means a lower tier number and more autonomy.

The Behavioral and Alignment components start at 100 for a new agent, so its starting tier depends mostly on the Risk Profile Score you set at creation. OpenBox also gives you an aggregate trust view across all agents, so you can read the crew's overall posture at a glance.

Configuring Governance Decisions for CrewAI Agent Actions

OpenBox evaluates each governed CrewAI action and returns one of four governance decisions: ALLOW, REQUIRE_APPROVAL, BLOCK, or HALT. When several policies apply, precedence runs HALT > BLOCK > REQUIRE_APPROVAL > ALLOW, so a single HALT ends the session regardless of the others.

Here is what each decision does, and how it shows up in a real crew.

You produce these decisions in the Authorize phase two ways. Policies are stateless OPA/Rego checks that evaluate a single operation and return allow, deny, or require_approval. Behavioral Rules are stateful and catch multi-step patterns, covered next. Trust-tier conditions let you apply stricter decisions to lower-tier agents.

Two settings decide how the SDK behaves when a decision needs a human or when Core is unreachable. hitl_enabled (default True) makes the SDK poll until a REQUIRE_APPROVAL resolves. governance_policy chooses your failure mode: fail_open (default) turns a network error into a soft allow so the crew keeps running, and fail_closed raises an error instead. Choose this deliberately before production.

Setting Behavioral Rules for Agent Coordination and Handoffs

Behavioral Rules are stateful authorization rules that watch for multi-step patterns across a governed agent's session, rather than judging one action in isolation. They detect sequences, frequencies, and combinations, which is what you need when work passes between agents and the risk only appears across several steps.

A policy asks whether one operation is allowed. A Behavioral Rule asks, given what this agent already did, whether the next action is allowed. Three pattern shapes from the OpenBox docs:

You build a rule from a Trigger (the action being checked, such as http_post) and one or more Required Prior States (actions that must have happened first, such as file_read). If the prerequisite is not met, OpenBox applies the verdict you configured: ALLOW, REQUIRE_APPROVAL, BLOCK, or HALT. Rules run in priority order and stop at the first one that fires.

This is what governs coordination. In a Researcher-to-Writer handoff, you can require that a report is only written after the database was actually queried, so a downstream agent cannot build output on fabricated inputs, or that a payment step waits until the invoice was read. For hierarchical and delegated crews, the SDK preserves the active execution context, so each HTTP, database, file, and LLM call is attributed to the agent that made it rather than whichever agent opened the trace.

What to Monitor When Your Crew Is Running Live in Production

Monitor two streams from a governed CrewAI crew: task-boundary events (WorkflowStarted and WorkflowCompleted per agent session, ActivityStarted and ActivityCompleted per task) and operational telemetry (HTTP, database, file, and LLM-gate activity). HTTP, database, and LLM-gate capture are on by default; file I/O is off until you enable it.

Use task boundaries for business-policy decisions. Treat hook-level telemetry as operational context for investigation, and write hook-level policy only when you genuinely need to govern a runtime operation directly. Governing every hook as though it were a business action creates duplicate approval flows.

OpenBox ties the streams together with correlation identifiers: a session id per agent, an execution id per crew, and a flow_execution_id when the crew runs inside a wrapped CrewAI flow. That is what lets nested and delegated runs render coherently, with Session Replay in the Verify phase showing the decision timeline for any operation.

For evidence, each completed session is hashed into a Merkle tree with SHA-256 and signed with ECDSA NIST P-256 through AWS KMS by default, producing a tamper-evident proof certificate that carries the Merkle root, signature, and event count. Over time, the Adapt phase surfaces violation patterns, trust recovery status, and tier changes, so you can tighten policy based on what the crew actually did.

Full Code Walkthrough

The full integration is four moves: install the SDK, provision one OpenBox agent per role and set its environment variables, swap Agent and Task for OpenBoxAgent and OpenBoxTask, then run the crew through engine.govern(crew). Your crew structure stays recognizable.

1. Set one environment prefix per governed role

OPENBOX_URL=https://core.openbox.ai

OPENBOX_RESEARCHER_API_KEY=obx_live_your_api_key

OPENBOX_RESEARCHER_DID=did:aip:550e8400-e29b-41d4-a716-446655440000

OPENBOX_RESEARCHER_PRIVATE_KEY=base64_ed25519_seed

OPENBOX_WRITER_API_KEY=obx_live_your_api_key

OPENBOX_WRITER_DID=did:aip:6f9619ff-8b86-d011-b42d-00c04fc964ff

OPENBOX_WRITER_PRIVATE_KEY=base64_ed25519_seed

2. Govern the crew

from crewai import Crew, Process

from openbox import OpenBoxAgent, OpenBoxTask, create_openbox_engine

researcher = OpenBoxAgent(

    role="Researcher",

    goal="Find information",

    env_prefix="OPENBOX_RESEARCHER",

)

writer = OpenBoxAgent(

    role="Writer",

    goal="Draft a summary",

    env_prefix="OPENBOX_WRITER",

)

research_task = OpenBoxTask(

    description="Research AI governance patterns.",

    expected_output="A short summary.",

    agent=researcher,

    activity_type="research",

)

write_task = OpenBoxTask(

    description="Write a brief from the research.",

    expected_output="A one-page brief.",

    agent=writer,

    activity_type="writing",

)

crew = Crew(

    agents=[researcher, writer],

    tasks=[research_task, write_task],

    process=Process.sequential,

)

with create_openbox_engine() as engine:

    result = engine.govern(crew).kickoff()

For async crews, wrap the same call:

with create_openbox_engine() as engine:

    result = await engine.govern(crew).akickoff()

After a governed run, OpenBox shows a session per governed agent, ActivityStarted and ActivityCompleted for each task, any approvals, blocks, or halts that policy required, HTTP and database telemetry attached to the activity, and flow correlation metadata when the crew runs inside a wrapped flow. Keep one engine per process, give each agent its own env_prefix, and enable file instrumentation only when you need to govern file operations.

For the same governance patterns in other stacks, see the OpenBox Developer Hub for governing agents with LangChain, LangGraph, and Temporal.

Frequently Asked Questions

Can I add OpenBox governance to a CrewAI crew without changing how the agents are defined?

Not entirely, but the change is small. You keep your crew structure, tasks, and process, then swap the governed Agent and Task for OpenBoxAgent and OpenBoxTask, add an env_prefix per agent, and wrap the crew with engine.govern(crew). The rest stays recognizable.

What happens to the rest of the crew when one agent's Trust Score drops below a threshold?

Trust Scores are per agent, so a drop downgrades that agent's tier and tightens its controls, not the whole crew's. Downgrades apply immediately. Other agents keep their own scores. Because policies can reference an agent's trust tier, you can also gate specific actions on the affected agent alone.

How does OpenBox handle governance for CrewAI tools like web search, code execution, and API calls?

Tool activity surfaces as hook-level telemetry: outbound HTTP such as web search and API calls, plus database operations, are captured by default, file operations when enabled, and an LLM-gate at the before-LLM-call hook. You can write hook-level policy, though OpenBox recommends task boundaries for business decisions and hooks for defense in depth.

Is there a performance overhead to adding Trust Score evaluation to each CrewAI agent?

Each governed task boundary and enabled hook adds a governance call to OpenBox Core, with a default 30-second timeout. Tier 1 agents auto-approve most operations for minimal latency impact. You control the overhead by choosing which layers to instrument, since file I/O is off by default, and by setting fail_open so a Core outage becomes a soft allow rather than a stall.

OpenBox brings CrewAI governance to production today. The SDK is published as openbox-crewai-sdk-python and developed in the open on GitHub under the MIT license. Verify the current integration status and configuration at docs.openbox.ai.

Sources

OpenBox, Getting Started with CrewAI. https://docs.openbox.ai/getting-started/crewai  Accessed 15 July 2026.

OpenBox, CrewAI SDK (Python). https://docs.openbox.ai/developer-guide/crewai  Accessed 15 July 2026.

OpenBox, CrewAI Integration Guide (Python). https://docs.openbox.ai/developer-guide/crewai/integration-walkthrough  Accessed 15 July 2026.

OpenBox, CrewAI Configuration. https://docs.openbox.ai/developer-guide/crewai/configuration  Accessed 15 July 2026.

OpenBox, CrewAI Approvals and Guardrails. https://docs.openbox.ai/developer-guide/crewai/approvals-and-guardrails  Accessed 15 July 2026.

OpenBox, CrewAI Telemetry. https://docs.openbox.ai/developer-guide/crewai/telemetry  Accessed 15 July 2026.

OpenBox, Trust Scores. https://docs.openbox.ai/core-concepts/trust-scores  Accessed 15 July 2026.

OpenBox, Trust Tiers. https://docs.openbox.ai/core-concepts/trust-tiers  Accessed 15 July 2026.

OpenBox, Governance Decisions. https://docs.openbox.ai/core-concepts/governance-decisions  Accessed 15 July 2026.

OpenBox, Behavioral Rules. https://docs.openbox.ai/trust-lifecycle/authorize/behaviors  Accessed 15 July 2026.

OpenBox, Adapt. https://docs.openbox.ai/trust-lifecycle/adapt  Accessed 15 July 2026.

OpenBox, Attestation and Cryptographic Proof. https://docs.openbox.ai/administration/attestation-and-cryptographic-proof  Accessed 15 July 2026.

openbox-crewai-sdk-python on PyPI. https://pypi.org/project/openbox-crewai-sdk-python/  Accessed 15 July 2026.

OpenBox-AI/openbox-crewai-sdk-python on GitHub. https://github.com/OpenBox-AI/openbox-crewai-sdk-python  Accessed 15 July 2026.

APPENDIX

Not for publication in the article body. This is implementation guidance for the web and editorial teams and is excluded from the article word count.

A1. SEO Metadata

Internal links (add before promotion, with the anchor text shown):

• OpenBox Developer Hub (parent pillar this spoke supports)  (hub page URL)  anchor: governing AI agents with LangChain, LangGraph and Temporal

• docs.openbox.ai/developer-guide/crewai  (https://docs.openbox.ai/developer-guide/crewai)  anchor: OpenBox CrewAI SDK

• docs.openbox.ai/core-concepts/trust-scores  (https://docs.openbox.ai/core-concepts/trust-scores)  anchor: how Trust Scores are calculated

• docs.openbox.ai/core-concepts/governance-decisions  (https://docs.openbox.ai/core-concepts/governance-decisions)  anchor: the four governance decisions

• docs.openbox.ai/trust-lifecycle/authorize/behaviors  (https://docs.openbox.ai/trust-lifecycle/authorize/behaviors)  anchor: Behavioral Rules

A2. JSON-LD Schema

Pre-filled with this article's values. Validate with Google's Rich Results Test before publishing. Keep the schema light; broken schema earns nothing.

TechArticle

{

  "@context": "https://schema.org",

  "@type": "TechArticle",

  "headline": "CrewAI Agent Governance: How to Add Trust Scores to Your Multi-Agent Crew",

  "description": "Your CrewAI crew runs clean in dev. Add OpenBox trust scores, approval gates, and audit trails so it behaves the same in production.",

  "author": { "@type": "Person", "name": "Tahir Mahmood", "jobTitle": "Chief Technology Officer and Co-Founder", "worksFor": { "@type": "Organization", "name": "OpenBox" } },

  "publisher": {

    "@type": "Organization",

    "name": "OpenBox",

    "logo": { "@type": "ImageObject", "url": "https://openbox.ai/logo.png" }

  },

  "datePublished": "2026-07-15",

  "dateModified": "2026-07-15"

}

FAQPage (must match the visible FAQ word for word)

{

  "@context": "https://schema.org",

  "@type": "FAQPage",

  "mainEntity": [

    {

      "@type": "Question",

      "name": "Can I add OpenBox governance to a CrewAI crew without changing how the agents are defined?",

      "acceptedAnswer": { "@type": "Answer", "text": "Not entirely, but the change is small. You keep your crew structure, tasks, and process, then swap the governed Agent and Task for OpenBoxAgent and OpenBoxTask, add an env_prefix per agent, and wrap the crew with engine.govern(crew). The rest stays recognizable." }

    },

    {

      "@type": "Question",

      "name": "What happens to the rest of the crew when one agent's Trust Score drops below a threshold?",

      "acceptedAnswer": { "@type": "Answer", "text": "Trust Scores are per agent, so a drop downgrades that agent's tier and tightens its controls, not the whole crew's. Downgrades apply immediately. Other agents keep their own scores. Because policies can reference an agent's trust tier, you can also gate specific actions on the affected agent alone." }

    },

    {

      "@type": "Question",

      "name": "How does OpenBox handle governance for CrewAI tools like web search, code execution, and API calls?",

      "acceptedAnswer": { "@type": "Answer", "text": "Tool activity surfaces as hook-level telemetry: outbound HTTP such as web search and API calls, plus database operations, are captured by default, file operations when enabled, and an LLM-gate at the before-LLM-call hook. You can write hook-level policy, though OpenBox recommends task boundaries for business decisions and hooks for defense in depth." }

    },

    {

      "@type": "Question",

      "name": "Is there a performance overhead to adding Trust Score evaluation to each CrewAI agent?",

      "acceptedAnswer": { "@type": "Answer", "text": "Each governed task boundary and enabled hook adds a governance call to OpenBox Core, with a default 30-second timeout. Tier 1 agents auto-approve most operations for minimal latency impact. You control the overhead by choosing which layers to instrument, since file I/O is off by default, and by setting fail_open so a Core outage becomes a soft allow rather than a stall." }

    }

  ]

}

A3. GEO and AEO Publishing Notes

A4. Open Items Before Publish

• Confirm the exact URL of the OpenBox Developer Hub pillar page and wire the in-body link and the pillar back-link.

• Author is set to Tahir Mahmood (CTO and co-founder); confirm his preferred credential wording before publish.

• Re-verify the CrewAI SDK version floor (Python >=3.10, CrewAI >=1.14.1) against docs.openbox.ai on the publish date, since the SDK is versioned.

• No PUBLISH BLOCKER: the openbox-crewai-sdk-python repo carries an MIT LICENSE (verified 15 July 2026), so the MIT claim is safe to publish.