Agent workflows need deterministic control, not just more autonomy

At a glance

What this is: This session argues that AI agents are useful precisely because they are less deterministic than traditional software, and that the hard problem is balancing emergent behaviour with control, observability, and reliable tool orchestration.

Why it matters: For IAM and identity practitioners, the lesson is that as agent workflows absorb more access and tooling, governance has to move from static permission design to runtime visibility, bounded delegation, and stronger lifecycle control.

👉 Read Stytch's agent-ready walkthrough on RAG workflows and agent development

Context

AI agents are software systems that can choose tools, combine outputs, and adapt their next step during execution rather than following a fixed script. That makes them operationally different from traditional application logic, because the identity problem is no longer only who signed in, but what the agent can do once it is running with delegated access.

For identity teams, this shifts the discussion toward tool orchestration, context handling, observability, and bounded access patterns. The more an agent can decide at runtime, the less useful static assumptions become about intent, execution order, and privilege duration.

Stytch's video frames that shift around practical agent development, using Langflow to show how teams build and inspect agent flows. The broader governance question is not whether agents will be used, but whether current control models can keep pace with the way they act inside production systems.

Key questions

Q: How should security teams govern AI agents that can use multiple tools?

A: Security teams should govern the reachable action set, not just the model or the user session. Map every tool, data source, and downstream system the agent can call, then apply explicit policy checks to higher-risk actions. The goal is to constrain what the agent can do at runtime, not to assume the prompt alone will keep it safe.

Q: Why do AI agents create a different identity risk than traditional automation?

A: Traditional automation follows predefined rules, while agents can choose tools and sequence actions at runtime. That makes privilege harder to define up front, because the effective access boundary depends on the session path. Identity teams need governance that accounts for dynamic delegation, not just scheduled or scripted execution.

Q: What do security teams get wrong about agent observability?

A: They often treat observability as a debugging feature instead of a control requirement. For agents, logs must capture prompt transitions, tool calls, intermediate decisions, and final outputs. Without that evidence, teams cannot audit policy compliance, investigate incidents, or explain why the agent took a particular path.

Q: What is the difference between agent autonomy and simple automation?

A: Automation follows a predefined process, even if it is complex. Autonomy means the system can decide what to do, which tools to use, and when to act during execution. That difference matters because autonomous behaviour changes the identity problem from controlling a workflow to governing runtime judgement.

Technical breakdown

LLM tool orchestration in agent workflows

An agent is not just an LLM. It is an LLM connected to tools, instructions, and a runtime loop that lets it decide whether to call one tool, several tools, or none at all. That tool layer is where the identity risk starts, because access is no longer limited to a single request or a single API call. The moment an agent can chain tools, the effective privilege boundary becomes the full set of reachable actions, not just the model itself.

Practical implication: Treat each tool connection as an identity boundary and review the reachable action set, not just the model endpoint.

Memory, context, and retrieval in agent design

Agent behaviour depends on short-term prompts, long-term embeddings, and procedural APIs, which means the system can behave differently depending on what context is present at runtime. That creates governance problems that traditional access control does not solve, because context can change the action path without changing the identity record. In practice, memory is part of the control surface, not just a feature.

Practical implication: Classify memory and retrieval sources as governance-relevant inputs and control what data they can influence.

Observability and debugging for non-deterministic execution

The article emphasises that logs and evals become more important in agentic systems because success is not binary. An agent may partially complete a task, take an unexpected path, or combine tools in a way that still produces output but breaks policy intent. Observability therefore has to capture decision paths, tool calls, and intermediate state, not only final outcomes. That is the only way to make agent behaviour auditable.

Practical implication: Instrument agent sessions so that every tool call, prompt transition, and decision branch is reviewable after execution.

Threat narrative

Attacker objective: The attacker wants to exploit delegated agent access so the system can take actions or reveal data beyond the intended control boundary.

1. Entry occurs when a user or system grants an agent access to tools, data sources, and instructions that let it operate beyond a simple chat interface. Escalation happens when the agent chains multiple tools or data sources together in ways that broaden its effective reach during the same session. Impact follows when that chained execution produces actions or outputs that exceed the original governance expectation.
2. The attacker objective is to turn delegated agent capability into uncontrolled execution paths that create policy drift, data exposure, or unsafe automated actions.

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

Deterministic control is the wrong default assumption for agent workflows: The article shows that agents are built to choose tools, recombine outputs, and adapt execution at runtime. That means governance designs based on fixed workflows, static intent, and predeclared action paths no longer describe how the system actually behaves. Practitioners should treat runtime delegation as the control problem, not just model quality.

Identity blast radius becomes a tool graph problem, not a login problem: Once an agent can reach multiple tools, the meaningful security boundary is the full graph of tool access and data movement. That is why agent governance has to account for context, orchestration, and downstream side effects, not only authentication. The implication is that access reviews must cover reachable actions, not just assigned accounts.

Observability is the governance layer that makes agent behaviour defensible: The piece is strongest when it connects debugging with operational control. If teams cannot see tool choice, prompt transitions, and intermediate outputs, they cannot explain why an agent acted as it did. That leaves security, compliance, and incident response without evidence. Practitioner implication: agent observability must be designed as an audit function, not a developer convenience.

AI agent identity is converging with NHI governance: The same lifecycle questions that govern service accounts now apply to agents that can call tools and hold context. That does not make an agent just another service account, because runtime decision-making changes the risk model. It does mean IAM and IGA teams should stop treating agent access as an application feature and start treating it as identity governance.

Runtime behaviour creates an identity governance gap that static provisioning cannot close: Provisioning was designed for known access at setup time. That assumption fails when the actor can select tools, alter execution order, and change its own path within a session. The implication is that practitioners must rethink how they define least privilege for systems whose effective privilege is discovered during execution, not assigned ahead of time.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how hard it is to govern non-human access at runtime.
• For a broader view of lifecycle and offboarding control gaps, see Ultimate Guide to NHIs and 52 NHI Breaches Analysis.

What this signals

Runtime governance will become the differentiator for agent programmes: teams that can log tool choice, intermediate reasoning, and action timing will be able to defend agent behaviour in ways static access reviews cannot. The operational shift is toward proving what the agent did, not just who approved it.

With 91.6% of secrets remaining valid five days after notification, the broader lesson is that delayed response and static governance are already a known weakness in NHI programmes. Agentic systems amplify that weakness because their effective privilege can change inside the same session.

Identity blast radius: this is the practical measure of how far an agent can move once it receives delegated access. If teams cannot bound the blast radius across tools, memory, and connected systems, they are governing an interface rather than the identity behind it.

For practitioners

• Define tool-level trust boundaries Inventory every tool an agent can call, classify the data each tool can reach, and document the maximum reachable action set for each workflow. The control target is the tool graph, not just the model endpoint.
• Instrument runtime decision paths Log prompts, tool selections, intermediate outputs, and final actions so security and compliance teams can reconstruct why a session behaved the way it did. Keep those records searchable by session, actor, and tool.
• Separate orchestration from authorization Do not let the same workflow logic both decide the task and approve the access path. Put explicit approval or policy checks around high-risk tool calls, especially where an agent can reach external systems.
• Review agent context as governed input Treat embeddings, retrieval sources, and procedural APIs as part of the security boundary. Limit which data sources can shape decisions and establish retention and redaction rules for sensitive context.

Key takeaways

• AI agents change the identity problem because they can decide which tools to use during execution, not just respond to a fixed workflow.
• Observability and tool-level governance are no longer optional in agentic systems because policy intent must be auditable after the session ends.
• IAM and NHI programmes need to treat agent access as runtime identity governance, not as a simple extension of application access control.

Key terms

• AI Agent: A software entity that can decide which actions to take, which tools to use, and when to execute them during a session. In identity terms, the agent behaves like a non-human identity whose effective privilege can shift at runtime, so governance has to cover execution paths as well as access entitlements.
• Tool Orchestration: The process of connecting an agent to multiple external tools so it can combine outputs and continue a task. From an identity perspective, orchestration expands the reachable action set and can create privilege chains that are invisible if teams only review the model or prompt layer.
• Observability: The ability to inspect what a system did, not just whether it produced an output. For agentic systems, observability must include prompts, tool calls, intermediate decisions, and final actions so security teams can audit behaviour, investigate incidents, and prove policy compliance.
• Agentic Workflow: A workflow in which an AI system can choose actions and sequence them at runtime instead of following a fixed script. The control challenge is that the system's effective privilege may emerge during execution, which makes static approval models incomplete on their own.

What's in the full article

Stytch's full video covers the hands-on development detail this post intentionally leaves for the source:

• Live Langflow walkthrough showing how the agent flow is assembled step by step.
• Demo of short-term prompts, long-term embeddings, and procedural APIs working together in one workflow.
• Practical observability examples using Arize evals to inspect agent execution paths.
• Discussion of how developers choose different models and tools for different steps in a multi-agent design.

👉 Stytch's full video shows the Langflow demo, observability examples, and multi-agent workflow breakdown.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.