Mixed-mode execution means the agent can move between structured tools and shell commands depending on the task. That creates a harder governance problem because the identity boundary is no longer singular. Programmes need to know which paths are allowed, how each path is logged, and what revocation looks like across both remote and local execution.
How mixed-mode execution changes the identity problem
Mixed-mode agent execution means one agent can operate through governed tool calls in one moment and direct shell execution the next. That changes identity governance from a single access path to a mixed control plane, where the same actor may need different entitlements, logging, approval, and revocation rules depending on the execution mode.
The practical issue is not just whether the agent is allowed to act, but how identity and access are governed across different execution paths. A programme that only models API-style tool access will miss the added exposure from local commands, while a programme that only thinks in shell terms may overlook scoped remote authorization and delegation.
For identity governance, mixed-mode execution also means the control objective shifts from “who is the agent” to “which path was used, under which authority, and with what blast radius.” That is why the governance model has to account for path-specific ownership, approval, and evidence, not just a single agent record.
Why logging and revocation must be path-aware
Mixed-mode execution makes auditability more important because the same business action can leave very different traces. Structured tool use can usually be tied to a service boundary, while shell execution may depend on local process context, inherited environment, or operator-adjacent access. If those are logged the same way, investigators lose the sequence needed to reconstruct what actually happened.
Revocation is just as tricky. A clean remote permission change does not necessarily stop a local command path that is already available, and a shell restriction does not automatically remove delegated tool access. Teams should expect to manage access review and certification as a cross-path control, because the question is whether access has been removed everywhere the agent can operate, not just in the primary orchestration layer.
Mixed-mode environments also benefit from explicit lifecycle thinking. If the agent can gain, reuse, or retain credentials across modes, then offboarding and rotation are not separate hygiene tasks, they are the mechanism that prevents one execution mode from surviving the revocation of another. Joiner, mover and leaver controls become relevant because mode changes behave like privilege changes in practice.
What identity governance should insist on
Mixed-mode execution is easier to govern when the organisation treats each mode as a distinct policy boundary. Tool mode should have explicit scopes, delegated authority, and deterministic logging. Shell mode should have tighter approval, stronger command visibility, and a clear rule for when interactive or local execution is permitted at all.
That separation matters most when organisations need to know whether the agent is using a controlled capability or borrowing human-like access. If shell commands can reach systems that the structured path cannot, then the governance question is no longer abstract privilege management, it is whether the agent is effectively bypassing the intended control model. Identity for AI agents is useful here because delegation, registration, ownership, and retirement all need to line up with execution mode.
Practitioners should also think about segregation of duties. If one mode can perform actions that the other mode is supposed to request or verify, the agent may unintentionally collapse approval and execution into a single path. Segregation of duties for bots and AI agents helps frame why mixed-mode designs need explicit conflict checks, not just generic least privilege language.
Risk and Threat Considerations
Mixed-mode execution expands the attack surface because an attacker, or a misconfigured workflow, can shift from the safer governed path into the more permissive local path. That creates a governance gap where a control that looks effective in one mode may be bypassed in another, especially when credentials, logs, or approvals are not consistent across both paths.
Failure mechanism: The agent obtains or reuses authority in one mode, then uses the alternate mode to exceed intended scope, evade normal logging, or retain access after revocation. NHI issue tracking is relevant because over-privilege, lifecycle gaps, and secret reuse are exactly the conditions that make mixed-mode control drift harder to see.
Impact: Organisations can lose traceability, fail to revoke access cleanly, and expose systems to privilege escalation or unauthorized local execution that was never intended in the agent’s original approval. At scale, the same design flaw can turn into repeated governance exceptions across many agents, not just one.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Mixed-mode agents rely on credentials and tokens that must be rotated and revoked across paths. |
| AC-6 — Least Privilege | Mixed-mode execution needs path-specific privilege limits to prevent fallback escalation. | |
| AU-2 — Event Logging | Governance depends on distinguishing structured tool actions from local command execution. | |
| Recommendation — Manage agent credentials so revocation works across both tool and shell execution paths. Limit each execution mode to the minimum permissions it actually needs. Log each execution mode with enough detail to reconstruct who did what, where, and how. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Mixed-mode agents can overreach when identity and privilege differ across tool and shell paths. |
| Recommendation — Bind agent authority to the execution mode and prevent privilege carryover across modes. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Mixed-mode execution often hides excessive access in one of the available paths. |
| NHI-01 — Improper Offboarding | Revocation must remove access from every execution mode, not only the primary one. | |
| Recommendation — Reduce each agent path to the least privilege needed for its role. Revoke tool, shell, and credential access together during offboarding. | ||
Practitioner Guidance
What to prioritise: Define separate rules for tool execution and shell execution before production rollout. If the policy cannot answer which mode is allowed, who approves it, and how it is logged, the agent is not yet governable.
What to verify: Test revocation in both directions. Confirm that removing remote permissions also blocks local fallback paths, and that disabling shell access does not leave delegated tool authority intact. The control only works if an operator can prove both paths are gone.
Decision rule: If the agent can reach a higher-trust system through shell than through tools, treat that as a design exception, not a normal convenience. Mixed-mode access should narrow the allowed path set, not silently widen it.
Practitioner takeaway: The key governance question is not whether the agent is powerful, but whether every execution mode is separately authorized, separately logged, and separately revocable.