Agentic AI examples in Python reveal the limits of deterministic code

At a glance

What this is: This is a hands-on comparison of deterministic Python scripts and agentic AI examples, with the key finding that agentic systems shift control from fixed code paths to goal-driven runtime decisions.

Why it matters: It matters because IAM, NHI, and human governance models all assume predictable execution boundaries, and agentic systems start to blur those assumptions in ways existing controls do not cleanly handle.

👉 Read WorkOS's analysis of agentic AI examples in Python

Context

Agentic AI examples matter because they show a software pattern that is no longer just deterministic automation. The primary governance question is how identity, privilege, and tool access behave when a system accepts a goal, plans at runtime, and changes execution based on what it learns.

That shift matters for identity programmes because the subject is not a human user, but a non-human executor that can call APIs, write state, and continue across steps. Once decision-making moves into runtime, static entitlement thinking becomes a weaker fit than controls built around scoped access, traceability, and bounded delegation.

Key questions

Q: How should security teams govern agentic AI examples in production?

A: Security teams should govern agentic AI examples as runtime identities with bounded delegation, not as ordinary automation. That means limiting tools, scoping access to a specific task, logging reasoning and actions, and separating read-only from state-changing operations. The control objective is to prevent scope drift while the agent plans, retries, and adapts.

Q: Why do agentic systems complicate least privilege?

A: Agentic systems complicate least privilege because the exact action sequence is not fixed in advance. Traditional entitlement design assumes the actor’s intent is known at provisioning time, but an agent decides at runtime which tools to call and when to call them. That makes task scope, fallback limits, and tool validation more important than broad standing access.

Q: What breaks when an AI agent can retry and widen scope on failure?

A: When an AI agent can retry and widen scope on failure, the original approval boundary stops being stable. The system may expand its own search window, chain more tool calls, or repeat state-changing actions without a fresh review. The result is governance drift, where the final output looks normal but the action path exceeded the intended boundary.

Q: What should teams do before giving an agent access to business tools?

A: Teams should classify each business tool by impact, add explicit allowlists for the agent’s permitted actions, and require human approval for irreversible operations. They should also test fallback paths, because escalation logic can expand privilege under failure. If the agent can touch calendars, tickets, or deployment systems, treat the access as privileged and auditable.

Technical breakdown

Deterministic scripts versus goal-driven agent loops

Deterministic code follows a prewritten path: if X happens, do Y. Agentic systems instead keep a loop of plan, act, observe, and refine until they reach a success condition or a guardrail stops them. That difference matters because the control surface moves from code review alone to runtime authorisation, tool validation, and state management. In practice, the agent is not just calling functions faster. It is deciding when to call them, which changes the trust model around every external dependency it touches.

Practical implication: treat agent loops as governed execution environments, not just smarter scripts.

Memory, tools, and fallback logic create a new identity boundary

The five pillars in the article are goal input, memory, tool interface, reasoning loop, and fallback limits. Together they define how an agent persists context, selects actions, and recovers from failure without redeploying code. From an identity perspective, the important point is that tool wrappers become the real privilege boundary, while memory becomes part of the attack surface if it can persist sensitive context or steer future actions. Fallbacks also matter because they can widen behaviour under failure.

Practical implication: review tool permissions, stored state, and retry logic as one control plane.

Why agentic AI examples change the way least privilege is applied

Least privilege in deterministic systems can often be mapped before execution begins. In agentic systems, the exact path is not fully known in advance, so privilege must be bounded by what the agent may do at runtime, not by a single predicted workflow. That makes validation, allowlisting, and task-scoped constraints more important than broad reusable access. It also means auditability has to include the reasoning trail and action sequence, not just the final outcome. The article’s examples show this clearly across scheduling, support, rollback, and content workflows.

Practical implication: define agent permissions around task scope, not around assumed intent.

Threat narrative

Attacker objective: The objective is to turn legitimate agent autonomy into a control bypass that produces harmful or unauthorized business actions through approved tools.

1. Entry begins when an AI agent is granted legitimate access to calendars, ticketing, content, or operational tools for a stated goal. The access is not malicious at the start, but it is broad enough to let the system act independently inside the authorised boundary.
2. Credential or privilege abuse happens when the agent uses its tool set and memory to expand what it can do during the session, such as retrying, widening scope, or chaining multiple actions without additional human approval. The risk is not stolen credentials, but uncontrolled runtime delegation.
3. Impact appears when chained actions affect scheduling, support, rollback, publishing, or research output at machine speed, leaving only the final state and logs as evidence. The attacker objective is to hijack or misdirect autonomous execution so the agent produces unintended business actions at scale.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Agentic AI examples create an assumption collapse in how IAM defines stable intent. Least privilege was designed for actors whose purpose can be inferred at provisioning time. That assumption fails when the actor decides what to do next at runtime, because the scope of access is not fully knowable before execution begins. The implication is that identity governance has to stop pretending intent is fixed when the executor is deciding in-session.

Dynamic tool use turns the tool interface into the real policy boundary. The article’s five-pillar model shows that memory and tool wrappers are not implementation details. They are the points where runtime behaviour becomes identity behaviour, which means they deserve the same scrutiny as privileged access paths in NHI programmes. Practitioners should treat every tool call as a governed action, not a harmless function invocation.

Agentic systems expose a gap between business approval and machine execution speed. Human review processes are too slow to sit in front of every decision an agent can make, especially when fallback logic can widen scope after an error. That is not a tuning issue, it is a control-model mismatch. The implication for practitioners is to redesign governance around bounded delegation, not around manual exception handling.

Runtime authorisation for agentic AI needs a different audit question than traditional automation. Deterministic automation asks whether the right job ran. Agentic governance asks whether the actor stayed inside the right action space while it was reasoning, retrying, and adapting. That shift is why agentic AI belongs in the same governance conversation as NHI, even when the implementation looks like ordinary Python.

Agentic AI examples sharpen the case for identity blast radius thinking. Once a system can call multiple tools in sequence, the blast radius is no longer a single permission. It is the combined effect of memory, fallback behaviour, and delegated APIs acting together. Practitioners should evaluate the full action chain, not just each individual entitlement in isolation.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• As agentic systems spread, governance needs to move from static secret handling to runtime identity control, and the OWASP Agentic AI Top 10 is the right forward reference for that shift.

What this signals

Agentic AI examples are becoming the new operational proxy for NHI sprawl. The programme risk is not only more identities, but more identities that can change what they do mid-session. With 6 distinct secrets manager instances on average in the field, fragmentation already weakens control consistency, and agent-driven execution increases the value of a central policy layer that can see the full action chain.

The practical signal is that teams should stop evaluating these systems as isolated automations and start treating them as governed executors with state, memory, and tool power. That means aligning controls to the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 where runtime decisions and delegated access meet.

Identity blast radius: the unit of control is no longer a single credential or one API call. It is the combined effect of access, memory, retries, and tool chaining across the agent’s full execution path. Teams that can model that blast radius early will have a clearer path to governance than teams waiting for a human review cycle to catch it.

For practitioners

• Inventory every agent-facing tool wrapper Map each API, shell, database, or SaaS action an agent can invoke, then classify the business impact of each call. Separate read-only access from state-changing access and require explicit approvals for high-risk tool categories.
• Bound agent permissions by task scope Define what the agent may do for a specific job, then cap the available tools, datasets, and fallback paths to that scope. Avoid shared broad credentials that persist across unrelated goals or sessions.
• Log the full reasoning-to-action chain Capture prompts, intermediate decisions, tool selections, retries, and final outputs so auditors can reconstruct why the agent acted. Logs that only show the end result will not explain scope drift or unsafe delegation.
• Test fallback behaviour under failure conditions Simulate missing data, tool errors, and low-confidence paths to see whether the agent widens its search, repeats actions, or escalates safely. The goal is to identify where fallback logic expands privilege or business impact.
• Compare agent governance to the OWASP Agentic AI Top 10 Use the OWASP Agentic AI Top 10 and Analysis of Claude Code Security to evaluate tool misuse, memory abuse, and control gaps before deployment. This keeps the assessment anchored to runtime behaviour rather than vendor-specific implementation choices.

Key takeaways

• Agentic AI examples show that runtime decision-making shifts governance from fixed scripts to bounded delegation and tool control.
• The evidence points to a widening secrets and access management problem, with remediation lag and fragmentation already weakening control confidence.
• Practitioners should govern agent behaviour as identity behaviour, using task scope, audit trails, and tested fallback limits as core controls.

Key terms

• Agentic System: An agentic system is software that accepts a goal, plans actions, uses tools, and adapts its next step based on what happens. In identity terms, it behaves like a non-human executor whose access must be bounded by task scope, not just by a static role.
• Runtime Delegation: Runtime delegation is the practice of letting software choose and sequence actions during execution rather than following a fixed script. For identity governance, it means the real control point is the permitted action space at the moment of execution, not only the original provisioning decision.
• Scope Drift: Scope drift happens when an actor starts within an approved boundary and gradually expands beyond it during the same session or task. In agentic environments, retries, fallback logic, and chained tool calls can quietly widen impact even when the initial access looked reasonable.
• Identity Blast Radius: Identity blast radius is the total operational damage an identity can cause if its permissions, memory, and delegated tools are misused. For agentic systems, the blast radius is shaped by chained actions, persistence, and fallback behaviour, not by one credential alone.

Deepen your knowledge

Agentic AI examples, runtime delegation, and tool-scoped access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for systems that reason and act at runtime, it is worth exploring.

This post draws on content published by WorkOS: Agentic AI Examples. Read the original.