The assumption that conflicting duties are hard to complete collapses when an assistant can move across functions almost instantly. Mitigating controls that depend on human delay or operational friction become weaker, because the risky combination can be executed before review or intervention happens. Governance has to account for speed, not just authority.
Why This Matters for Security Teams
When AI assistants can execute SAP workflows at machine speed, the main failure is not just privilege excess. It is the collapse of control assumptions that depend on human pause, ticketing delay, or manual review. Segregation of duties, approval queues, and after-the-fact exception handling all become weaker if an assistant can chain actions across finance, procurement, HR, and inventory before anyone notices.
This is especially dangerous in ERP environments because one identity often touches many business-critical functions. Traditional role design assumes predictable user behavior, but an assistant can follow a goal across systems, retrieve context, and complete a risky sequence without the friction that once made the sequence detectable. NIST guidance on governance and access control in the NIST Cybersecurity Framework 2.0 is still relevant, but the control model has to be evaluated against autonomous execution, not just named roles.
NHIMG research on the State of Secrets in AppSec shows how fast exposure and remediation gaps can be when secrets are in motion, and the same timing problem applies to agentic workflows. In practice, many security teams discover toxic combinations only after the assistant has already completed the workflow chain, rather than through intentional prevention.
How It Works in Practice
The practical answer is to move from static permission thinking to runtime control. For SAP-connected assistants, that means treating the assistant as a workload with scoped, short-lived authority rather than as a human surrogate with broad standing access. Current guidance suggests pairing workload identity with just-in-time credential issuance, then evaluating each workflow step against policy at request time.
That usually means:
- Use workload identity to prove what the assistant is, not who last logged in.
- Issue ephemeral secrets or tokens per task, and revoke them when the task ends.
- Apply policy-as-code so approvals, financial thresholds, and data sensitivity are checked at runtime.
- Separate tool access from business authority, especially where SAP transactions can trigger downstream effects.
- Log each action at the workflow level, not just the session level, so chained behaviour is visible.
Frameworks such as SPIFFE and runtime policy systems are useful because they align access with the current task, not an inherited role. For SAP-specific risk analysis, NHIMG’s LLMjacking research is a reminder that compromised non-human identities can be abused very quickly once credentials or tokens are exposed. This is why speed matters: a safe-looking assistant in the morning can become a cross-function execution path by afternoon.
These controls tend to break down when SAP customisations, legacy RFC interfaces, and shared service accounts are already embedded across business units because policy enforcement becomes inconsistent at the integration boundary.
Common Variations and Edge Cases
Tighter control often increases operational overhead, requiring organisations to balance workflow velocity against approval latency and integration complexity. That tradeoff is real in SAP landscapes where batch jobs, exception handling, and shared service accounts still support core operations. Best practice is evolving, and there is no universal standard for exactly how much autonomy an assistant should have inside ERP.
One common edge case is read-heavy assistants that only summarise SAP data. Even there, excessive read access can reveal payroll, pricing, or supplier data that should not be broadly exposed. Another edge case is emergency operations, where humans deliberately grant broader access for incident response. Those exceptions need time-bounded controls and auditable justification, or they quietly become standing privilege.
NHIMG’s State of Secrets in AppSec highlights how quickly confidence can outpace actual control maturity, which is a useful warning for SAP automation programmes. For organisations standardising their governance baseline, NIST Cybersecurity Framework 2.0 and emerging agent governance guidance should be mapped together, not treated as separate initiatives.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | Agentic execution speed can bypass human review and safe workflow assumptions. |
| CSA MAESTRO | GOV-02 | Governance must account for autonomous workflow execution across business systems. |
| NIST AI RMF | GOVERN | The issue is governance of autonomous decision-making under uncertainty and speed. |
Set accountability, oversight, and escalation rules for assistant-driven SAP workflows.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
