Notifications
Clear all
Topic starter
11/07/2026 8:25 pm
TL;DR: AI agents combine LLMs, tools, prompts, and observability to create non-deterministic workflows that are harder to debug and govern than traditional software, according to Stytch. The key issue is that existing identity and control assumptions were built for stable execution paths, not runtime tool choice and within-session behaviour.
NHIMG editorial — based on content published by Stytch: Agent ready episode 1 with Langflow on RAG workflows and agent development
Questions worth separating out
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.
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.
Q: What do security teams get wrong about agent observability?
A: They often treat observability as a debugging feature instead of a control requirement.
Practitioner guidance
- 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.
- 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.
- Separate orchestration from authorization Do not let the same workflow logic both decide the task and approve the access path.
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.
👉 Read Stytch's agent-ready walkthrough on RAG workflows and agent development →
AI agent workflows: what happens when control and autonomy collide?
Explore further
11/07/2026 8:54 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Agent workflows need deterministic control, not just more autonomy
