How should organisations evaluate AI agents that act across multiple systems?

They should evaluate the full trajectory, not just the final response. That means capturing tool calls, retrievals, retries, and state changes, then checking those claims against source-of-truth systems. If the agent updated a record, opened a PR, or triggered a workflow, the environment must confirm it happened before the run is treated as successful.

Why This Matters for Security Teams

Evaluating an AI agent that spans multiple systems is a control problem, not a prompt-quality problem. A polished answer can still hide unsafe tool use, unauthorized writes, stale retrievals, or workflow actions that never completed. The right question is whether the agent’s end-to-end behaviour was safe, traceable, and consistent with approved authority. That framing aligns with the NIST AI Risk Management Framework, which treats governance, measurement, and monitoring as core risk disciplines rather than afterthoughts.

Security teams often miss the boundary between reasoning and execution. A model may appear accurate while a downstream connector silently fails, retries, oversteps scope, or mutates records in a way the operator never intended. This is especially important where agents have access to ITSM, code repositories, ticketing systems, cloud consoles, or identity workflows, because a single unsafe action can propagate across environments. The current guidance from the OWASP Agentic AI Top 10 is to evaluate agentic systems with explicit attention to tool abuse, excessive authority, and output integrity.

In practice, many security teams encounter agent risk only after a workflow has already changed state, rather than through intentional pre-deployment validation.

How It Works in Practice

Practical evaluation starts by reconstructing the full run, not just the final response. That means logging the agent’s inputs, retrieved context, intermediate reasoning artifacts where appropriate, tool calls, retries, approvals, and every system mutation. Security and engineering teams should then compare each claimed action against the source of truth, such as the CMDB, code host, ticketing platform, SIEM, IAM system, or cloud control plane. Where the agent makes decisions that affect access or production systems, the record should show who authorised the action, what policy allowed it, and what the environment actually accepted.

A useful assessment usually combines three checks:

• Did the agent use only the systems and scopes it was allowed to use?
• Did each action succeed in the target system, or merely appear successful in the model output?
• Did the final outcome remain consistent with policy, business rules, and rollback expectations?

For threat modelling, teams can map likely failure modes to the MITRE ATLAS adversarial AI threat matrix, especially prompt injection, tool manipulation, and data poisoning that influence agent behaviour across systems. Where an agent is part of a production workflow, the control set in NIST SP 800-53 Rev 5 Security and Privacy Controls is still relevant for logging, access enforcement, change control, and auditability. The evaluation should also include negative testing, for example malformed inputs, stale retrievals, conflicting instructions, and attempts to chain benign tools into harmful outcomes. These controls tend to break down when agent permissions are broad, logs are incomplete, and downstream systems accept partial or asynchronous updates without a reliable completion signal.

Common Variations and Edge Cases

Tighter evaluation often increases runtime, logging volume, and operational overhead, requiring organisations to balance observability against performance and privacy constraints. There is no universal standard for how much chain-of-action detail must be retained for every agent, so best practice is evolving. High-trust internal assistants may justify lighter evidence capture, while agents that can move money, alter identities, or deploy code need much stronger traceability.

Edge cases appear when agents act across partially trusted domains. For example, an agent may be allowed to draft a change request but not submit it, or to recommend an IAM update but not approve entitlement changes. In those cases, evaluation should separate recommendation quality from execution authority. Another common issue is asynchronous systems: a tool call may return success before the downstream platform finalises the update, so the assessment must verify state convergence rather than relying on a single API response. This is also where agent governance intersects with identity controls, because NHI-style credentials, service accounts, and delegated tokens need explicit scoping and revocation discipline. The broader pattern is that multi-system agents are safest when every meaningful action has a verifiable owner, a bounded credential, and an observable outcome.

Related resources from NHI Mgmt Group

• How should organisations respond when an AI agent inherits access across multiple systems?
• What breaks when an AI agent can act across multiple business systems?
• What should organisations do with consent when agents can act across multiple tool calls?
• How should security teams model AI agents that can read, act, and delegate across systems?