Identity and access challenges grow because agentic AI expands the set of actors that may request actions, use credentials, or trigger workflows. In a Secure by Design model, teams must decide which identities are human, service, or agent driven, then apply least privilege, strong authentication, and explicit approval paths. Without that clarity, access boundaries blur and governance becomes harder to enforce.
Why Secure by Design raises the bar for identity decisions in agentic SAP environments
Secure by Design changes the question from “can this workflow run?” to “which actor is allowed to run it, on what authority, and with what blast radius?” In SAP environments, that matters because agentic ai may sit inside business processes, orchestration layers, or support tooling that already touch sensitive ERP data. Once agents can initiate transactions or call downstream systems, identity becomes the control boundary that decides whether automation is useful or unsafe.
That boundary is harder to hold because SAP programs often blend human approvals, technical integrations, and delegated workflow steps. An agent can look like a user from the application’s point of view, like a service from the platform’s point of view, and like an automation from the business process point of view. Secure by Design therefore demands explicit classification, not assumptions, so teams know when a request should inherit human intent, when it should use a service credential, and when it should be blocked pending review.
When that classification is vague, three things usually degrade together: permission scope, traceability, and exception handling. Overbroad access creeps in because teams want the workflow to keep moving; audit trails become less meaningful because the effective actor is unclear; and temporary exceptions tend to become permanent. That is why identity and access problems do not just increase in volume, they become harder to reason about operationally.
The practical implication is that the Secure by Design posture must be visible at the identity layer. The organisation needs a crisp answer for whether the agent is acting as a named service principal, a constrained workflow identity, or a human-in-the-loop proxy, because each option changes approval design, entitlement review, and incident response. For broader context on non-human identity governance, see Ultimate Guide to NHIs and the section on key NHI security challenges and risks.
Where the control model usually breaks down
The hardest failures are rarely technical in isolation. They appear when SAP process ownership, IAM ownership, and AI governance ownership are split, so no one team can explain who granted the access, why it was granted, or how it will be revoked. Agentic systems amplify that weakness because they can move faster than manual review cycles, especially when a business process expects automatic continuation after a trigger event.
One common failure mode is privilege inheritance by convenience. If the agent is wired into an existing integration account, it may inherit broad access that was originally designed for batch jobs or trusted middleware, not for an actor that can choose actions dynamically. Another failure mode is approval collapse, where the agent’s recommendations are treated as if they were the approval itself. In that case, Secure by Design is weakened because the control exists on paper but not at the decision point.
Identity sprawl also rises quickly in SAP landscapes because the same underlying business function may be exposed through multiple channels, such as APIs, workflow engines, RPA, and chat interfaces. That multiplies the number of identities, secrets, and entitlements that must be aligned. If the access path is not inventoryed, teams cannot tell whether a failure is caused by a bad role, a stale secret, an overpermissive connector, or an agent that should never have had tool access in the first place.
For a concrete illustration of why overprivilege and credential exposure matter in non-human contexts, the Microsoft SAS Key Breach shows how a single overly permissive token can widen exposure far beyond the original use case. The broader attack path is also well documented in 52 NHI Breaches Analysis.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Agentic SAP workflows depend on non-human credentials that must be tightly managed. |
| NHI-02 — Identity and Access Lifecycle | The question centers on classifying and governing human, service, and agent identities. | |
| NHI-04 — Privilege and Access Control | Least privilege and explicit approval paths are the core control problem here. | |
| Recommendation — Constrain and rotate automation credentials with explicit ownership and revocation paths. Inventory and govern each non-human identity with a clear lifecycle and owner. Apply least privilege to agent access and require approval for high-impact actions. | ||
| OWASP Agentic AI Top 10 | A2 — Agent Authorization and Tool Access | Agentic SAP actions depend on tightly bounded tool and action authorization. |
| A4 — Identity, Authentication, and Delegation | The answer hinges on deciding whether the actor is a human, service, or agent delegate. | |
| Recommendation — Limit each agent to explicit tools, scopes, and action boundaries. Define delegation rules that distinguish human intent from autonomous execution. | ||
| CIS Controls v8 | 6 — Access Control Management | This is fundamentally an access-boundary and entitlement-governance problem. |
| 5 — Account Management | Agentic SAP environments expand the number of accounts and service identities to manage. | |
| Recommendation — Remove unnecessary access and review entitlements for automation paths regularly. Track every account used by automation and disable unused identities promptly. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The subject is about establishing and enforcing identity-aware access boundaries. |
| GV.OV — Oversight | Secure by Design requires accountable oversight for autonomous and delegated access. | |
| Recommendation — Implement strong identity proofing, authentication, and access enforcement for agent actions. Assign governance ownership for agentic workflows and their access decisions. | ||
| NIST SP 800-63 | SP 800-63B — Authentication and Lifecycle Management | Agent and service credentials need robust authenticator and lifecycle handling. |
| Recommendation — Use phishing-resistant authenticators and manage credential lifecycle tightly. | ||
Practitioner Guidance
What to verify: Verify that every agentic SAP action has a single accountable identity path, meaning you can trace the actor, the credential, the approval, and the downstream system touched. If any one of those elements is missing, the workflow is not yet operating in a Secure by Design state.
Decision rule: If the agent can initiate business-impacting actions, treat it as a privileged automation and constrain it with explicit entitlements, short-lived access where possible, and human approval for irreversible steps. If the agent only drafts recommendations, keep it away from direct execution rights.
What practitioners underestimate: The main risk is not only excess privilege, but ambiguity. Once humans, services, and agents are allowed to share loosely defined access paths, governance degrades even when each individual control still appears to exist.
Practitioner takeaway: Secure by Design succeeds in agentic SAP environments only when access is designed around clearly bounded actor types, not around the convenience of the workflow.
Related resources from NHI Mgmt Group
- Why does identity security become harder when workloads and AI agents are part of the access model?
- Why does identity become the control plane in agentic AI environments?
- Why do self-managed AI gateways become harder to govern as agentic AI and tool access expand?
- Why do cloud-native environments become harder to secure as teams add more pipelines, workloads, and AI-assisted development?
