AI agent engineering still hinges on deterministic control

At a glance

What this is: Hyland’s AI agent approach centres on deterministic behaviour, runtime guardrails, and online evaluation for agents that act on enterprise content.

Why it matters: For IAM, NHI, and agentic AI teams, the key issue is that tool-using agents inherit identity and access risk from the systems they can touch, not just from the model that powers them.

👉 Read Arize’s analysis of Hyland’s AI agent engineering approach

Context

AI agent engineering becomes an identity governance problem when the system can select tools, move across data boundaries, and take real actions in enterprise workflows. In that setting, reliability is not just model accuracy, it is whether access, context, and execution stay within the boundaries the organisation intended.

The article’s core point is that production agents need deterministic behaviour, human review for high-risk workflows, and monitoring that proves the same request produces the same outcome over time. That places the discussion squarely in the overlap between agentic AI identity, NHI governance, and enterprise access control rather than simple application development.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: What breaks when AI agents are allowed to operate without deterministic validation?

A: Plausible output can be mistaken for evidence, which is dangerous in offensive testing and in production workflows. Without deterministic validation, the same agent that suggests a weakness can also overstate it, chain into unsafe actions, or produce results that cannot be reliably audited. The control failure is trust without proof.

Q: How do organisations know when an approved AI agent needs re-review?

A: Re-review is needed when the agent’s prompt, model, tools, or reachable data changes enough to alter its behaviour baseline. Security teams should also re-check after new integrations, scope expansion, or unexpected access patterns. In practice, any drift from the approved runtime profile should trigger a fresh decision.

Technical breakdown

Why deterministic agent behaviour matters in enterprise workflows

Deterministic behaviour means the same input, context, and policy state produce the same action path, even when the underlying model is probabilistic. For enterprise agents, that matters because tool calls, document retrieval, and workflow actions can have business and security impact. If behaviour varies across runs, the organisation cannot reliably reason about access decisions, escalation paths, or audit evidence. Online evaluation and observability are therefore not just ML quality controls. They are the mechanism that shows whether the agent remains inside its intended operating envelope when data formats, prompts, or context change.

Practical implication: require repeatable output and action traces before allowing agents to touch business workflows or sensitive data.

How MCP tool registration expands the identity surface

Model Context Protocol gives an agent a standard way to connect to tools and data sources, which makes integration easier but also enlarges the trusted execution surface. Every registered tool becomes a potential access path that must be governed, logged, and constrained. In practical terms, the agent does not just consume data. It can invoke APIs, reach across systems, and act on records if the surrounding policy design allows it. That is why tool inventory, approval boundaries, and per-tool authorization matter as much as model safety in agentic architectures.

Practical implication: maintain a live inventory of every MCP-connected tool, with explicit authorization and logging for each one.

Why human-in-the-loop remains a control, not a fallback

Human-in-the-loop is best understood as a governance boundary for tasks that are too risky for fully autonomous execution. In enterprise settings, some agent actions should progress only to recommendation, draft, or queued approval, especially when they can alter records, trigger payments, or change access. The article’s emphasis on escalation paths reflects a practical truth: agent confidence is not the same as operational trust. A controlled review step preserves accountability when the workflow has high business impact or ambiguous context.

Practical implication: define which agent actions can execute, which require review, and which must stop at recommendation only.

Threat narrative

Attacker objective: The objective is to use trusted agent execution to reach business data, tools, or workflow actions that were never meant to be available in that combination.

1. Entry occurs when an enterprise agent is granted access to documents, APIs, and workflow tools through federated or registered connections. Escalation happens if the agent can combine those tools with insufficiently constrained context or overly broad permissions. Impact follows when a non-deterministic action path changes records, exposes data, or drives the wrong business decision at scale.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Determinism is the governance requirement, not a product preference. Enterprise agents that touch content, tools, and workflows need repeatable action paths because IAM and audit controls depend on stable behaviour. If the same request can lead to different tool calls or approvals, policy enforcement becomes inconsistent and evidence quality degrades. The practitioner conclusion is that reliability is a governance property, not only an engineering metric.

Agentic AI identity extends the NHI problem, but it does not replace it. Once an agent can authenticate to systems, invoke tools, and move across data boundaries, the control question becomes who or what is acting, under which permissions, and with what review boundary. That is a direct extension of NHI governance into runtime decision-making. The practitioner conclusion is to treat the agent as an identity-bearing system with tool-scoped accountability.

Context engineering is the new access control layer for agent workflows. The article shows that prompt quality alone cannot protect enterprise actions when context determines what the agent sees and does. Preserving security mappings between central and on-prem systems matters because the agent’s effective privilege is shaped by the context it can retrieve. The practitioner conclusion is that access design and retrieval design now share the same governance surface.

Human review remains necessary because autonomous confidence is not operational certainty. The article’s escalation-path approach reflects a broader identity lesson: some workflows still require a deliberate handoff between machine suggestion and accountable approval. That applies equally to NHI governance and to agentic AI, where speed must not erase attribution. The practitioner conclusion is to define where automation stops and accountable review begins.

Repeatability is the named concept that separates useful agents from risky ones. Repeatability means the agent produces the same governed outcome across changing data, formats, and contexts. Without it, online evaluation cannot prove that access paths and workflow actions remain inside policy. The practitioner conclusion is that repeatable behaviour is the minimum acceptable condition for production deployment.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, which means 48% still operate with a complete blind spot for compliance and breach investigation.
• For a broader control lens, OWASP NHI Top 10 helps teams map agent tool risk to concrete governance actions.

What this signals

Repeatable behaviour is becoming the deciding control for production agents. When the same prompt can lead to different tool calls, the programme loses policy consistency and the audit trail becomes weaker. The practical response is to treat online evaluation and action tracing as core access governance, not just model quality work.

As agent workloads expand, identity teams need a separate view of tool-scoped privilege. Agents that bridge documents, APIs, and workflows can exceed the original access intent even when no human is directly manipulating the flow. That makes connected tools the real control plane for governance decisions.

With 80% of organisations already seeing agents act outside intended scope, the gap is no longer theoretical. Teams should prepare for access reviews, logging, and escalation design that assume runtime behaviour can drift faster than traditional review cycles can catch it.

For practitioners

• Define deterministic execution boundaries Map which agent actions must always follow the same path, then block any workflow where the action sequence can drift across runs.
• Inventory every connected tool and data source Treat MCP registrations, APIs, and federated connectors as governed access paths, and require explicit ownership for each one.
• Separate recommendation from execution Route high-risk tasks through human review, especially where the agent can alter records, trigger approvals, or expose sensitive content.
• Test behaviour under changing data conditions Use online evaluation against format shifts, content changes, and retrieval changes so the agent is validated on repeatability, not just accuracy.
• Preserve security mappings across boundaries Keep access entitlements aligned when agents move between central platforms and on-prem systems, so retrieval does not create unintended privilege expansion.

Key takeaways

• AI agent governance now depends on repeatable action paths, not just model accuracy or prompt quality.
• Connected tools, federated access, and workflow integration expand the identity surface that security teams must control.
• Production readiness requires human review boundaries, online evaluation, and access governance that can survive changing context.

Key terms

• Non-Deterministic Behaviour: Non-deterministic behaviour is software behaviour that does not produce the same outcome every time under similar inputs. In AI systems, this makes traditional testing and code review incomplete unless teams also capture and analyse production outcomes.
• Context Engineering: The practice of selecting, curating, and delivering the information an AI system uses at runtime. In agentic environments, context engineering is a security function because the quality, provenance, and trust level of the inputs directly shape the system’s actions and outputs.
• Online evaluation: Online evaluation scores production AI traffic after it has been logged, rather than only during testing. It gives teams a running view of how a policy performs in real use, which is essential when prompts, models, and user behaviour keep changing.
• MCP Tool Registration: MCP tool registration is the process of exposing tools and APIs to an AI agent through the Model Context Protocol. Each registered tool becomes part of the agent’s governed access surface and needs ownership, logging, and permission boundaries.

What's in the full article

Arize's full analysis covers the operational detail this post intentionally leaves for the source:

• How Hyland structures Agent Builder, Agent Core Runtime, and MCP registration in production
• The online evaluation and observability workflow used to validate repeatable agent behaviour
• How federated access and on-prem connectivity are handled across enterprise content systems
• The specific runtime monitoring and alerting expectations for multi-tenant agent environments

👉 Arize’s full post covers the runtime, evaluation, and integration details behind Hyland’s agent stack.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.