Agent tooling moves trust from model output to capability, credential and review boundaries

Three recent Red Hat engineering projects point to a practical shift in AI-agent governance: teams are moving trust decisions away from the model’s final answer and toward boundaries the surrounding platform can inspect, restrict or require a human to cross.

The projects address different stages of an agentic workflow. AgentTrust audits whether an agent behaves within the capabilities it advertises. The DCI MCP server joins operational evidence from systems with separate credentials. Code-to-Docs separates AI-generated suggestions from repository mutation through a two-command review loop.

Together, they suggest that “trust the model” is the wrong unit of control. Platform teams instead need controls at delegation, data access and write time.

Capability claims need behavioral evidence

Agent2Agent agent cards and similar discovery documents tell a caller what an agent claims it can do, but they do not enforce that scope. AgentTrust generates in-scope, out-of-scope and near-miss probes from those declarations, then scores the response. Where MLflow traces are available, it also compares the answer with the tools the agent actually invoked.

That distinction exposes failures hidden by fluent text. An agent can refuse an out-of-scope request after calling an undeclared tool, or answer an in-scope request from model memory instead of the live source implied by its contract. AgentTrust turns those discrepancies into audit evidence, although Red Hat describes the framework as experimental, single-turn and post-hoc; runtime interception remains future work.

The useful control point is the delegation boundary. A platform can test whether a capability claim corresponds to observed behavior before allowing other agents to rely on it. The score is not proof—the project notes the circularity of one LLM judging another—but it is more inspectable than accepting self-description alone.

Credential scope defines the real MCP boundary

The DCI MCP server shows a different risk: one conversational interface can hide several access domains. Its tools and prompts can combine DCI job artifacts, Jira history, GitHub or GitLab changes, Red Hat support cases, advisories and Google Drive output into a root-cause report.

The repository configures those integrations with separate credentials, and some controls are explicit. Jira write operations require a separate JIRA_WRITE_ENABLED=true switch. GitLab restricts model-supplied instance URLs to the configured host unless an operator adds an allowlist. Those are platform-enforced boundaries; a prompt cannot grant itself a Jira write path or redirect a GitLab token to an arbitrary host without the surrounding configuration permitting it.

Deployment choices still matter. The README documents an HTTP/SSE endpoint but does not describe authentication for that endpoint, while reports and downloaded evidence can be written under /tmp or exported to Google Drive. Network authentication, token scope, local retention and document sharing therefore determine the practical security boundary—not the fact that the interface speaks MCP.

Human review belongs immediately before mutation

Code-to-Docs places its strongest control between suggestion and write. A collaborator first comments [review-docs]; the Action proposes affected documentation files with checkboxes. A reviewer can remove files and must issue a separate [update-docs] command before the workflow creates a documentation pull request.

The sample workflow accepts commands only from repository owners, members or collaborators and grants the Action write-capable GitHub permissions. A second pull request preserves an ordinary code-review checkpoint after the AI-assisted selection. The optional Jira specification review also warns that ticket and linked-document content will appear in a pull-request comment, making repository visibility part of the data boundary.

Design the chain, not only the model

These projects do not form a complete policy stack, and none eliminates model error. They do identify three control questions that platform teams can apply now: does observed behavior match the capability contract; can each credential reach only the intended system and operation; and does a human-approved event stand between generation and mutation?

That framing makes agent governance less dependent on detecting every bad output. It gives teams places to deny, record and review an action even when the model remains probabilistic.