## Weekly signal

The week’s clearest signal: human-agent trust is becoming a systems engineering discipline. The center of gravity is shifting away from broad AI ethics language and toward controls that can be inspected: identity, authorization, traceability, independent validation, escalation, rollback, and evidence.

That matters because agents are different from chatbots. A chatbot can mislead. An agent can mislead, click, call tools, update records, trigger payments, open tickets, spawn sub-tasks, or pass bad context to another agent. Trust therefore depends less on whether the model sounds confident and more on whether the surrounding system limits damage and proves what happened.

This week’s useful developments clustered around four layers: public security guidance, frontier-model evaluation, agent behavior validation, and enterprise identity/accountability.

## What changed

1. Five Eyes guidance became the practical baseline for agent risk reviews.

The most important item for builders and enterprise buyers was the joint guidance on careful adoption of agentic AI services from Australia’s ASD, U.S. CISA/NSA, Canada, New Zealand, and the UK. Although first published May 1, it shaped the week’s discussion because it translates agentic AI risk into deployment controls that security teams can actually use.

The guidance is directly relevant to human-agent trust because it says the quiet part out loud: agents can be opaque, fast, interconnected, over-privileged, and difficult to attribute. In multi-agent systems, one compromised agent can spread incorrect information, exploit trust and consensus mechanisms, operate through hidden channels, or cause cascading failures. The agencies also call out accountability risks: delegation chains, stochastic behavior, fragmented logs, and reasoning traces that are too large or poorly structured for human oversight.

The recommended controls are specific enough to become procurement and launch gates. They include sandboxing before production, red teaming, capability probing, multi-agent red teaming or chaos testing, fail-safe defaults, containment, rollback to known-good behavior, comprehensive artifact logging, unified audit logs for inter-agent interactions, trusted registries for third-party components, allow-listed tools and versions, human-readable tool logs, automatic permission restriction when unexpected behavior emerges, separation of duties across roles such as orchestrator, reader, and actuator, and human-in-the-loop approval for high-stakes actions.

The trust implication: “we trust the agent” is no longer a defensible control. A better claim is: “we know who owns it, what it can touch, what it did, why it did it, how to stop it, and how to recover.”

2. Pre-deployment model evaluation expanded in the United States.

On May 5, NIST’s Center for AI Standards and Innovation announced agreements with Google DeepMind, Microsoft, and xAI for pre-deployment evaluations and targeted research. NIST said the agreements build on prior partnerships and allow evaluation of models before they are publicly available, as well as post-deployment assessment and other research. CAISI also said it has completed more than 40 evaluations, including some on unreleased state-of-the-art models.

This is not agent certification. It does not prove a bank’s AML agent, a coding agent, or a customer-service agent is safe. But it is relevant to human-agent trust because frontier model capabilities set the floor for what downstream agents can do. A model with stronger planning, cyber, persuasion, or tool-use capabilities changes the risk profile of any agent built on it. Independent pre-release evaluation gives enterprises another input into model governance: which model versions are allowed, what safeguards changed, what risks were found, and whether a workflow needs extra approval or containment after an upgrade.

The practical takeaway for builders is to separate model trust from workflow trust. Model evaluations can inform selection, but production trust still requires task-level controls, tool-level permissions, monitoring, and human accountability.

3. GitHub’s “Trust Layer” reframed agent testing around outcomes, not scripts.

On May 6, GitHub published a technical post on validating agentic behavior when correctness is not deterministic. The post focuses on Copilot-style coding and computer-use agents operating in real environments such as UIs, browsers, IDEs, and GitHub Actions workflows. GitHub’s point is highly practical: agent behavior can vary while still being correct. A loading screen may appear, timing may shift, or the agent may take a different valid path to the same result. Traditional record-and-replay or step-by-step tests can fail even when the agent completed the task.

GitHub proposes a “Trust Layer” based on dominator analysis. Instead of requiring the exact same action trace, the method learns essential milestones from successful runs and checks whether new executions reach those milestones in the right logical order. This gives developers a more explainable test: not just pass/fail, but which required state was missing.

The most important trust point is that GitHub explicitly compares this external structural validation with an agent’s own self-assessment. In its experiment, the agent self-report was materially weaker, while the dominator-tree method better distinguished success from failure. GitHub’s takeaway is that agents cannot yet reliably grade their own work in non-deterministic environments.

For builders, this is a strong pattern: never make the agent the only judge of whether the agent succeeded. Use external validators tied to observable outcomes and tool effects.

4. Identity teams are treating agents as governed non-human actors.

IBM’s Think 2026 identity recap, published May 8, framed agents as a new class of system that can make decisions, execute tasks, and call tools with minimal human oversight. IBM’s identity message is that AI agents need accountability paths similar to other non-human identities, but with extra attention to scope, tool access, and drift. The example risk is easy to understand: an agent that starts in a research setting can quietly end up touching patient data if no one can trace how it got there or who owns it.

This is a key human-agent trust issue. Users and operators need to know not only “which model answered,” but which agent acted, under whose authority, with which credentials, for which task, during which time window, and under which policy version. Without that, escalation and blame become ambiguous.

The builder implication is to design agent identity as a first-class object. Agents should not share generic service accounts. They need short-lived credentials where possible, scoped permissions, ownership metadata, approval rules, revocation, and lifecycle management from development through decommissioning.

5. Regulated deployments are keeping humans in the loop where stakes are high.

Amalgamated Bank announced on May 7 that it is working with FIS and Anthropic as a design partner on a Financial Crimes AI Agent for AML alert investigations. The agent is intended to assemble and evaluate information across systems and surface high-risk cases for investigator review. The bank emphasized governance, controls, risk discipline, and human judgment.

This is a useful implementation pattern. The agent is not framed as an autonomous compliance officer. It is a case-preparation and prioritization layer that helps humans review faster. In regulated workflows, this is likely the more durable adoption model: agents gather evidence, summarize, check consistency, and triage, while named humans make or approve consequential decisions.

Customer-experience vendors are also pushing trust features around reversibility and override. Sendbird’s May 7 launch of Agent Steward and Trust OS 2.0 is vendor-provided data, but the direction is consistent with the broader market: users care about stopping, overriding, correcting, and reversing agent actions, not just getting faster answers.

## What to do with it

For builders: start every agent design with an authority map. List the tools it can call, data it can read, records it can change, external messages it can send, and money or legal obligations it can affect. Then assign approval thresholds. Low-risk actions can be autonomous. Moderate-risk actions may require secondary agent or rule-based approval. High-risk actions need human approval, expiry-bound delegation, and logged rationale.

For platform teams: build an agent identity inventory now. Each agent should have a unique identity, owner, purpose, environment, model version, tool list, credential scope, retention policy, and kill switch. Treat “shadow agents” the way security teams treat unmanaged service accounts.

For evaluation teams: add external validators. Do not rely on the agent’s self-report. For coding agents, validate tests, diffs, build status, security scans, and required milestones. For workflow agents, validate tool side effects: was the ticket updated, was the refund within policy, was the customer notified, was approval captured? GitHub’s structural testing approach is a strong template for non-deterministic environments.

For compliance and risk teams: define what evidence you would need after a bad action. At minimum: prompt/context snapshot, retrieved sources, tool calls, credentials used, policy version, approval chain, output, user-visible explanation, rollback action, and reviewer notes. If you cannot reconstruct the event, you do not yet have operational trust.

For product leaders: make reversibility visible. Human-agent trust improves when customers and employees can pause, override, correct, escalate, and recover. This is especially important for customer service, finance, healthcare, HR, and legal workflows. A fast agent without a recovery path creates support debt and reputational risk.

The bottom line for the week: trustworthy agents are not just better models. They are bounded actors inside observable systems, with independent checks and accountable humans around them.