TL;DR: Agentic AI examples in Python show systems that accept goals, plan, adapt, and use tools across changing conditions, while deterministic scripts still require every path to be coded in advance, according to WorkOS. The control issue is not reasoning quality alone but governance over runtime decisions, privilege boundaries, and accountability when software starts acting like an identity-bearing executor.
At a glance
What this is: This is a WorkOS analysis of agentic AI examples in Python, showing how goal-driven systems differ from deterministic scripts because they plan, adapt, and use tools at runtime.
Why it matters: It matters because IAM and NHI programmes must govern runtime decision-making, tool use, and accountability differently once software behaves like an identity-bearing executor rather than a fixed workflow.
Context
Agentic AI examples in Python sit at the point where deterministic programming ends and runtime decision-making begins. A deterministic script follows predefined branches, while an agent can set a goal, select tools, and refine its next step as conditions change.
For identity teams, the core issue is not code style but governance model. Once a system can act across multiple tools and state transitions, controls designed for fixed execution paths no longer describe who or what is making the access decision.
The article uses Python examples to make that shift visible in practical terms. The patterns it shows are typical of the current wave of agentic AI adoption, where runtime behaviour matters more than static code paths.
Key questions
Q: What breaks when software can choose actions at runtime instead of following fixed code paths?
A: Fixed-path governance breaks when the next action is no longer known in advance. Access, logging, and approval models that assume deterministic branches do not fully cover systems that can plan, call tools, retry, and adapt mid-task. Teams need controls that bind each runtime action to explicit scope and auditability.
Q: When does agentic automation create more governance risk than it reduces?
A: It becomes riskier when the organisation cannot explain why a particular execution path was chosen, cannot verify reconciliation quickly, or cannot contain exceptions in legacy systems. At that point, speed is improving while assurance is degrading, which is the wrong trade-off for identity governance.
Q: What are the signs that an agentic workflow is exceeding its intended control boundary?
A: Warning signs include hidden retries, widening search windows, unlogged tool calls, persistent state that outlives the task, and fallback logic that keeps expanding scope. Those signals show the workflow is making governance decisions at runtime rather than staying inside a clearly bounded execution model.
Q: How should security teams govern delegated control in autonomous AI systems?
A: They should treat delegated control as a first-class identity problem, not a by-product of application integration. That means binding every action to a named owner, a defined purpose, and a constrained scope, then reviewing whether the agent still operates within those limits as its behaviour changes. Accountability must remain traceable throughout the agent lifecycle.
Technical breakdown
Deterministic scripts versus agentic AI examples in Python
Deterministic Python code encodes every branch ahead of time, so the system can only do what the developer has explicitly written. Agentic AI examples in Python instead pair an LLM with memory and tool APIs, then run a plan-act-observe-refine loop that decides which step to take next based on current state. That changes the security model because the execution path is no longer fixed at design time. The agent may still be bounded by validation, timeouts, and tool wrappers, but the action sequence emerges at runtime rather than from a hard-coded branch tree.
Practical implication: govern the tool layer and state transitions, not just the source code path.
Why runtime tool use changes identity governance
The article’s five pillars make the identity issue clear: goal input, memory, tool interface, reasoning loop, and fallback limits. In a deterministic workflow, the code decides in advance which API call happens next. In an agentic system, the software can choose among tools, retry with different parameters, and persist state for later use. That makes authorization, logging, and blast-radius design more important than static code review alone. The relevant question becomes whether each tool invocation is individually bounded, attributable, and revocable when the agent changes course mid-task.
Practical implication: treat every agent tool call as a governed access event with explicit scope and auditability.
Accountability gaps in goal-driven automation
The article repeatedly contrasts coded procedures with systems that can take a goal and improvise the path. That does not make the system autonomous in the strongest sense, but it does create delegated execution with less predictable timing and sequencing than traditional automation. For IAM and NHI governance, the challenge is that the operator may define the objective while the system discovers the steps. Accountability therefore shifts from a static approval chain to a runtime trace of decisions, tool selection, and fallback behaviour. The strongest control question is whether the delegated system can be explained after the fact without reconstructing the entire prompt and memory state.
Practical implication: require decision traceability for delegated execution, not just task completion logs.
Threat narrative
Attacker objective: The attacker objective in this pattern would be to abuse delegated runtime execution so the system performs actions, issues notifications, or accesses data beyond the intended scope.
- Entry occurs through a legitimate goal submission to the agentic system, not through a fixed script branch. The system then uses memory and tool APIs to pursue that goal.
- Credential or privilege use happens when the agent invokes privileged calendar, messaging, or workflow tools during execution. The scope is shaped at runtime rather than predeclared in a single code path.
- Impact appears when the agent can act across systems, persist state, and retry on failure, which expands the blast radius if its tool access or instructions are mis-scoped.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Deterministic control assumptions collapse once software can choose its own execution path: Branch-based governance assumes the next action is known at design time. That assumption fails when an agent forms a plan, selects a tool, and decides whether to retry or switch strategy at runtime. The implication is that access governance has to move from static path review to runtime authorisation and traceability.
Agentic AI examples in Python create an identity problem even when the actor is not fully autonomous: The article shows delegated execution, not unconstrained autonomy, yet the governance burden is already different from ordinary automation. A system that can call APIs, persist state, and refine its next action behaves like an identity-bearing executor for control purposes. Practitioners should classify the access path, not the marketing label.
Ephemeral decision loops demand ephemeral control windows: Traditional review and recertification logic assumes access persists long enough to inspect it later. Agentic systems can request, use, and discard access inside one task, which means governance cannot rely on post-hoc review alone. The practical conclusion is that entitlement scope and execution context must be bound together at issuance time.
Runtime tool selection is the new policy boundary: In these examples, the most material risk is not the model’s reasoning quality but the set of actions it can attempt through tools. Once tool wrappers mediate calendar, messaging, code, or database actions, the security boundary sits at the invocation layer. That boundary should be treated as a first-class governance control, not an implementation detail.
Agentic AI identity governance should be measured by recoverability, not novelty: If an organisation cannot reconstruct why a system acted, which tool it used, and what state it carried forward, the control model is incomplete. The article’s strongest lesson is that explainability after execution matters as much as correctness during execution. Practitioners should judge agentic readiness by how well they can bound and audit delegated action.
From our research library:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- Gartner predicts that by the end of 2026, 40% of enterprise apps will feature task-specific AI agents.
- Read next: Agentic AI Identity Guide
What this signals
Runtime control is now the governance boundary: When software can choose tools and adapt its path, static branch review is no longer enough. Identity teams should shift attention to issuance-time scope, traceable tool use, and revocation of delegated access when the task ends.
Agentic AI identity is not the same as ordinary automation: The article’s examples show delegated execution that can retry, persist state, and recover from failure, which means the control plane must follow the runtime behaviour. Teams that keep using human-style approval models will miss the real decision point.
Decision traces matter more than code paths: If a system cannot explain which tool it used and why, the organisation cannot prove that access stayed inside policy. That is the new audit requirement for agentic workflows.
For practitioners
- Define tool-level authorisation boundaries Map every API, shell, database, and messaging action an agent can invoke, then bind each one to explicit scopes, ownership, and revocation paths.
- Separate goal input from privilege assignment Avoid giving the same runtime entity both the objective and unrestricted access. Make tool access narrower than the task description and review it by action type.
- Log decision traces and state transitions Record prompt changes, tool selections, retries, and fallback branches so investigators can reconstruct why the system acted the way it did.
- Set hard guardrails on retries and escalation Cap retry loops, timeouts, and fallback behaviours so an agent cannot widen its own scope indefinitely when a task fails.
- Classify delegated systems by runtime behaviour Review whether the system merely automates a script or actually chooses actions at runtime, then apply the governance model that matches the behaviour.
Key takeaways
- Agentic AI examples in Python show why deterministic branch logic is no longer the only viable execution model for delegated work.
- The main governance issue is runtime tool use, because the system can change actions and recover from failure without code redeploys.
- Practitioners should bind access, logging, and revocation to each delegated action so runtime behaviour stays auditable and bounded.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article centres on agents selecting and invoking tools at runtime. |
| ASI03 — Identity & Privilege Abuse | Delegated execution raises privilege and accountability issues when runtime actions vary. | |
| Recommendation — Bound every agent tool call to explicit scope, approval, and audit logging. Treat delegated agent access as privileged and constrain its runtime authority. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is about how organisations govern agentic runtime behaviour. |
| Recommendation — Define ownership, traceability, and escalation rules for agentic systems under GOVERN. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Agent tool access must be explicitly scoped and authorised. |
| Recommendation — Apply PR.AA-05 to scope each agent action to the minimum required entitlements. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Agent misuse can expand access across tools and systems during execution. |
| Recommendation — Map runtime tool abuse to TA0006 and TA0008 when assessing blast radius. | ||
Key terms
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
- Deterministic Codemod: A deterministic codemod is a rule-based source code transformation that rewrites a known pattern into a safer equivalent. In Java remediation, it operates on the abstract syntax tree, so the fix is structurally valid and repeatable. This makes it suitable for repetitive security flaws that have a clear, standard repair path.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Decision trace: The record of how an access decision was made, including inputs, policy logic, and the final allow or deny outcome. For AI-assisted identity systems, decision traces are necessary for auditability, troubleshooting, and proving that automated access was bounded and explainable.
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 IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org