Agent workflows need deterministic control, not just more autonomy

At a glance

What this is: This is a Stytch video session on agent development that finds AI agent workflows need deterministic control, observability, and bounded tool orchestration to be governable.

Why it matters: It matters because IAM and security teams must govern how agentic systems choose tools, consume context, and expose execution paths, not just who can log in.

Context

AI agent workflows are software paths where an LLM can choose tools, combine outputs, and vary execution at runtime instead of following a fixed script. That makes them materially different from traditional application flows, even when they are embedded inside familiar product architecture.

For IAM and security teams, the governance gap is not whether agents are useful. It is whether current control models can cope with non-deterministic tool use, changing context, and execution paths that may not repeat the same way twice.

This Stytch session with Langflow frames the problem as a balance between autonomy and deterministic control. That balance is now a design requirement for agentic applications, not a nice-to-have feature of the development stack.

Key questions

Q: How should security teams govern AI agents that choose tools at runtime?

A: Security teams should treat runtime tool choice as a governed access event, not a normal application call. That means task-scoped credentials, explicit approval boundaries for sensitive actions, and logs that record both the tool selected and the identity used. If the agent can change its plan, the control model must be able to change with it.

Q: Why do AI agents make existing IAM controls harder to rely on?

A: Because many IAM controls assume access is stable long enough to be reviewed, certified, and revoked later. Agents can acquire, use, and release permissions within one session, which leaves little durable artefact for traditional lifecycle processes. That creates a governance gap between approval time and execution time.

Q: What are the signs that an agent workflow is becoming too non-deterministic?

A: Common signs include inconsistent execution paths for similar prompts, opaque tool selection, repeated dependency on stale context, and outputs that cannot be reproduced from logs. If engineers cannot explain why the agent picked one path over another, the workflow has likely outgrown its current control design.

Q: How should security teams decide whether an agent can use external tools?

A: They should authorise the session first, then allow tools only within that session’s scope. The decision should depend on cryptographic proof of the actor, the permitted task, and the destination, not on the tool name alone or the process path being present on an allowlist.

Technical breakdown

Why non-deterministic agent workflows change the control model

Traditional software follows a mostly predictable path, so controls can be designed around known states, fixed inputs, and repeatable outcomes. An AI agent changes that because the model can decide when to call tools, which tool to use next, and how to recombine results during the session. That makes the workflow stateful in a much looser sense than classic application logic. The security problem is not just complexity. It is that the execution path is partially chosen at runtime, which makes pre-authored assumptions about behaviour less reliable. For identity practitioners, the important question is whether the control point sits at login, at tool grant, or at each decision boundary. Practical implication: move governance closer to runtime decision points instead of relying only on static application design.

Practical implication: move governance closer to runtime decision points instead of relying only on static application design.

Memory, context, and tool orchestration as governance surfaces

The session highlights memory, context, and tool orchestration as the core operational surfaces in agent systems. Memory determines what the agent carries forward, context shapes the immediate decision frame, and tool orchestration decides what external actions the agent can take. In practice, those three surfaces can leak trust across steps if they are not bounded. An agent may act on stale context, reuse an assumption that no longer holds, or chain tools in ways the operator did not anticipate. That is why observability matters here: logs and telemetry are not just for post-incident review, but for understanding the actual policy boundary the agent crossed. Practical implication: treat memory and tool chaining as governed execution surfaces, not just application features.

Practical implication: treat memory and tool chaining as governed execution surfaces, not just application features.

Observability is part of control, not just troubleshooting

The video makes a useful point that agent observability is not the same as old-style logging. In deterministic systems, logs mainly help explain what went wrong after failure. In agentic systems, telemetry has to explain both success and partial success, because the system may take different paths to reach an acceptable result. That means evaluation signals, execution traces, and tool-use records become part of governance evidence. This is especially important when an agent is connected to external APIs or procedural actions, because the operator needs to know not only what the agent said, but what it attempted and what it touched. Practical implication: build traceability into the agent runtime so policy review is possible after every execution path.

Practical implication: build traceability into the agent runtime so policy review is possible after every execution path.

Breaches seen in the wild

• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Deterministic control is the missing governance layer for agentic systems. The article shows that autonomy without bounded execution creates workflows that are harder to reason about than conventional software. That is not simply an engineering inconvenience. It means identity and access control have to account for decision-making that occurs after the session starts, which changes how practitioners think about authorization boundaries.

Agent workflows expose an execution problem, not just an AI problem. The most important surfaces in the article are memory, context, and tool orchestration, because those are the points where runtime behaviour diverges from preplanned logic. When those surfaces are unbounded, the issue becomes governance of action, not just governance of data. Practitioners should read this as a call to control how actions are composed, not only who can invoke the system.

Observability becomes a control objective once agent behaviour is non-deterministic. The session’s emphasis on evals and runtime telemetry reflects a broader reality: if you cannot reconstruct what the agent decided and why, you cannot govern it. That pushes agent programmes toward auditable execution traces, policy-aware logging, and explicit tool-boundary design. The practitioner conclusion is straightforward: visibility is now part of the control plane.

Agent autonomy does not eliminate deterministic requirements, it raises them. The central design tension in the article is that users want flexible outcomes while operators still need bounded behaviour. That tension will shape the next generation of IAM and application governance, especially where agents can chain tools or external APIs. The field should stop treating autonomy as an exception and start treating deterministic control as the condition for safe deployment.

Runtime tool choice creates a new governance surface across identity and application teams. When an agent can select tools dynamically, the traditional separation between application logic and access governance breaks down. That makes the control problem cross-functional by design. The practitioner takeaway is to manage agent execution as a governed identity event, not just as a developer experience feature.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: Agentic AI Identity Maturity Model

What this signals

Deterministic control is now the operating constraint for agentic systems. As agents gain the ability to choose tools and combine outputs at runtime, governance has to shift from static permissioning to runtime-bound execution control. That means the first design question is no longer what the model can do, but what the system will allow it to do in a live session.

Tool orchestration is becoming an identity problem as much as an application problem. When an agent can call external services, the identity surface is no longer just login and session creation. It becomes the chain of permissions, context, and action boundaries that govern every tool hop across the workflow.

Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec. That gap matters in agentic systems because poorly governed inputs and credentials can turn flexible workflows into opaque operational risk.

For practitioners

• Define tool-boundary policy Specify which tools an agent may use, in what combinations, and under what session conditions before deployment. Keep the allowed action space narrow enough that runtime behaviour remains explainable.
• Instrument execution traces Capture tool calls, context changes, and intermediate outputs so every agent path can be reconstructed for review. Traceability should cover both successful and partial-success runs.
• Separate memory from authority Treat stored context as input, not entitlement. Do not let remembered state expand an agent’s effective permissions beyond the current task.
• Use evals as governance evidence Run continuous evaluation on agent outputs and tool behaviour to detect drift from intended policy. Make eval results available to security and platform teams, not only developers.
• Constrain multi-step tool chaining Limit how many external systems an agent can traverse in one workflow so a single prompt cannot cascade into broad, unreviewed execution.

Key takeaways

• AI agent workflows are governed by runtime decisions, so static application controls are not enough on their own.
• Memory, context, and tool orchestration are the main surfaces where autonomy turns into control risk.
• Observability is part of governance for agent systems because teams need to reconstruct how each execution path unfolded.

Key terms

• Agent Workflow: An agent workflow is a machine-driven sequence where an AI system can call tools, access data, and continue execution with limited human involvement. These workflows need governance that sees API activity and tool use, not just browser sessions or user clicks.
• Tool Orchestration: The control logic that determines when an agent should call a function, which function it should use, and how results flow into the next step. In practice, orchestration is part of the trust boundary because it determines which systems the agent can reach and in what sequence.
• Deterministic Controls: Deterministic controls are rules that produce predictable, repeatable outcomes for an AI agent’s actions. They remove ambiguity by enforcing predefined conditions, allowed paths, and stop points. In security testing, they help ensure the agent behaves consistently, stays within scope, and produces results that can be audited and trusted.
• Session Trace: A complete record of one agent run from the initial prompt to the final output. It usually contains nested spans for model calls, tool invocations, and handoffs, giving teams a timeline that shows sequence, duration, and context across the full task.

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 building or maturing an IAM programme, it is worth exploring.