How to Govern Non-Human Identities (NHIs) in the Age of Agentic AI

A practical guide to governing non-human identities (NHIs) — the service accounts, AI agents, workloads, bots, and integrations that now carry access across your enterprise.

The challenge of governing non-human identities has grown rapidly as teams connect applications, automate business processes, move workloads to the cloud, and expand the use of AI. Each of these initiatives can help your business operate more efficiently, introduce new capabilities, or better serve customers and employees. But they can also leave identities and credentials spread across systems that no one team can see or govern in full.

Bringing these identities under consistent governance means adapting the controls your organization already has to the way NHIs operate. Where many Identity and Access Management (IAM), Privileged Access Management (PAM), cloud, security, and DevOps controls were designed around human identities with stable accounts, predictable behavior, and clear ownership, NHIs behave dynamically, can be short-lived, and span multiple teams.

Agentic AI adds a further challenge because agents can adapt their actions in pursuit of an objective. For these identities, adapting existing controls means governing not only how access is granted, but also how it is used throughout a task.

This guide first sets out why non-human identities have outgrown controls designed for people, and how agentic AI changes the challenge further. It then provides a governance model to help you connect an identity’s purpose and ownership with how its access is granted, used, monitored, and withdrawn, including how to apply it by identity type and in SAP. Finally, a maturity path helps you decide where to start and what to prioritize.

Read on to navigate

01 — What GRC modernization means in practice

In many SAP-centric organizations, governance capabilities have evolved at different times and for different reasons. SAP GRC may have been introduced to address access risk, enterprise IGA added as the identity environment expanded, and other, separate processes developed for controls, audit, or cloud governance.

Over time, these changes commonly lead to overlapping tools, unclear ownership, duplicated controls, or governance processes that no longer reflect the underlying business. Modernization addresses these accumulated gaps by looking at how the different parts of the GRC environment work together and where they need to change.

For SAP-centric organizations, this usually means looking across five connected areas:

What modernization should achieve

A modern GRC model should be easier to operate, easier to evidence, better connected across systems and teams, and able to adapt as your business changes.

Architecture

Deciding how governance capabilities should be distributed across SAP GRC and SAP IAG, enterprise IGA platforms and privileged-access capabilities. This includes where SAP-native functionality is sufficient and where separate tooling is required.

People and ownership

Making sure risks, controls, access decisions, and remediation activities have clear owners with the authority and information to act.

Controls

Reviewing whether existing controls reflect current business processes, automating them where appropriate, and connecting them more closely to risk and audit.

Identity and access

Coordinating SAP-specific risk and role governance with your wider enterprise identity lifecycle.

Operations

Establishing the processes, review cycles, and governance forums that keep your model current as your business changes.

01. The non-human majority

Human lifecycle controls do not scale to machine identities

Non-human identities (NHIs) now outnumber human identities by more than 100 to one, according to Palo Alto Networks’ 2026 Identity Security Landscape report — a ratio that will continue to grow as organizations expand their use of cloud services, automation, and AI.

These are machine identities used by applications, services, and automated processes rather than people. They include service accounts and the identities behind cloud workloads, containers, APIs, robotic process automation (RPA) bots, integrations, and AI agents.

Unlike people, non-human identities don’t join, change roles, and leave on a predictable schedule. They are created through everyday technology activity: a new integration needs an account, a pipeline needs a secret, and a bot needs access to several applications. Some remain in place for years, while others are created automatically and exist for only seconds.

At that scale and speed, governing NHIs requires more than knowing which identities exist. Teams need to understand where each identity came from and what it is for, who is accountable for it, what it can reach, how it is being used, and when its access should end. That context can be difficult to come by when it’s fragmented across application, cloud, security, and operations teams, or when altering an unfamiliar credential could interrupt a critical process.

The non-human identity governance challenge is therefore not simply to eliminate every unknown immediately, but to replace uncertainty with enough context to make safe, risk-based decisions. That means identifying the highest-risk access, finding the people who understand its purpose and dependencies, and bringing it into a governed lifecycle — an approach we set out step-by-step later in this guide.

02. Where does agentic AI fit, and what makes it different?

AI agents behave and use access differently from other NHIs

Conventional non-human identities and AI agents share the same basic governance foundations. They need a defined purpose, an accountable owner, appropriate access, observable activity, and a reliable way to withdraw their authority. But sharing those foundations doesn’t mean agents operate in the same way as conventional NHIs. For example, a service account usually performs a repeatable function, whereas an agent may adapt its path as its context, inputs, and intermediate results change. The table below shows where those differences appear and what each one means for governance.

Dimension	Conventional non-human identity	Agentic identity	Governance implication
Purpose	Executes a defined function, job, or integration.	Selects or adapts actions in pursuit of an objective.	Record the purpose of the identity and the boundaries of the authority delegated to it.
Behavior	Expected actions are usually repeatable and easier to baseline.	The path can vary with context, inputs, and intermediate results.	Monitor actions and outcomes, rather than relying only on successful authentication.
Access pattern	Often uses a stable account, key, certificate, or secret.	May invoke several tools or systems during one chain of activity.	Evaluate the combined permission path and prevent broad standing access from becoming the default.
Lifecycle	May be long-lived and tied to an application or process.	May be created or invoked for a task, then become inactive or be replaced.	Link creation, validation, suspension, and removal of the workload or use case.
Failure mode	Stale credentials, unclear ownership, excessive access, or unrotated secrets.	Unintended action, privilege expansion, or lateral movement while optimizing for an outcome.	Provide rapid containment and revocation, with logs that preserve what the agent did and under which authority.

How does agentic behavior change the risk picture?

Because an AI agent can adapt its behavior, use several systems, and change course as a task unfolds, risk is shaped not only by the access initially granted but also by how that access is combined and used. An agent may begin with permission to complete a defined task, then call several tools, encounter new information, and adjust its next action. No single step may look excessive, yet risk can develop through the way those steps combine, the speed at which they occur, and the distance between the original approval and the eventual outcome. The five issues below show where that risk appears and what governance must account for.

Authority can outlive the original decision

When an agent is granted permission to complete a task, that access may remain available after the task has finished or its requirements have changed. Without clear limits on how long permissions remain valid and what they can be used for, an agent could continue accessing sensitive information or performing actions that were never part of the original approval.

Permissions can combine across a chain

An agent may interact with several applications and systems to complete a single task, using permissions that appear appropriate when reviewed individually. However, combining those permissions can give the agent access to information or capabilities beyond what was intended, potentially allowing it to move sensitive data between systems or perform unauthorized actions.

Behavior varies with context

Unlike conventional automation, which generally follows predefined instructions, agents can adapt their actions based on the information they receive and the results of previous steps. This makes their behavior harder to predict, increasing the risk that an agent will take an unintended action or access information outside its intended purpose without triggering conventional security alerts.

Consequences develop at machine speed

Agents can perform multiple actions across connected systems in a very short period, leaving little opportunity for human intervention when something goes wrong. An agent operating with excessive permissions could modify records, expose sensitive information, or trigger further automated processes before the activity is detected and its access can be revoked.

Identity and execution become separate governance questions

Knowing which agent accessed a system does not necessarily explain why it performed a particular action or whether that action was authorized. Without records linking the agent's identity to its delegated permissions, decisions, and resulting activity, organizations may struggle to investigate incidents, establish accountability, or demonstrate that sensitive operations remained within approved boundaries.

03. The NHI governance model

How to govern access from its original purpose through use and revocation

Any non-human identity can develop a gap between why its access was approved and how that access is actually used. For a long-lived service account, that gap can widen slowly as purposes change and owners move on. For an AI agent, it can open within a single task. An access decision therefore only remains meaningful if the controls applied during the activity continue to reflect the identity’s approved purpose, which requires IAM and PAM to work together.

IAM provides the context for a decision: why an identity exists, who is accountable for it, what policy applies, how access was approved, and when it should be reviewed. PAM controls how privileged credentials and authority are issued, used, monitored, and withdrawn. When the two operate without shared context, an organization may know that a credential was used without knowing whether the underlying purpose or approval is still valid.

A connected model carries the approved purpose and risk context into execution, then feeds activity and changes back into certification, containment, and removal decisions. Before an identity is approved, the organization should be able to answer five questions — one for each governance foundation: What is it for? Who is accountable for it? What may it do? How will its activity be observed? What will cause its authority to be reviewed or withdrawn?

The five workstreams below build that control chain. They are shown separately because different teams may lead them, but they work as a cycle: discovery creates visibility, ownership establishes purpose and accountability, least privilege constrains access, monitoring makes activity observable and reveals when access or policy needs to change, and revocation withdraws authority when it is no longer justified.

Workstream 1

Discovery and inventory

Signals to investigate

Service accounts that are unknown or undocumented.
Credentials embedded in application code or scripts.
Incomplete or inconsistent inventories across cloud platforms, applications, infrastructure, APIs, and automation tools.

Actions

Identify non-human identities and credentials across the estate, including cloud environments, applications, infrastructure, and automation tools.
Consolidate the findings into a central inventory.
Record each identity's type, environment, purpose, credentials, privileges, dependencies, and last observed use.
Include short-lived workloads by recording how and where identities are created, rather than relying solely on persistent account records.

Outputs

A governed inventory that identifies which services depend on each identity and provides a starting point for assigning ownership and assessing risk.

Workstream 2

Lifecycle ownership

Signals to investigate

Accounts with no clear business purpose or identified owner.
Identities associated with projects or suppliers that are no longer active.
Owners who cannot confirm whether an identity still needs access.
Access reviews that overlook temporary or short-lived identities.

Actions

Assign an accountable owner who understands the business process supported by each identity and can confirm its purpose.
Identify a technical custodian responsible for maintaining its credentials and security controls.
Document how the identity is created, when its access should be reviewed, and what should trigger its suspension or removal.
Link each identity to the relevant business service so that changes to systems, processes, or ownership prompt a review.

Outputs

Clear accountability for each identity, supported by documented lifecycle requirements, access review records, and criteria for removing access when it is no longer needed.

Workstream 3

Least privilege

Signals to investigate

Identities, particularly agents, with broad or permanent access beyond their immediate requirements.
Long-lived credentials that are rarely changed.
Agents and other identities that can access multiple systems without additional authorization.
Approval processes that cannot keep pace with automated activity.

Actions

Establish which tasks an identity needs to perform and which systems and data it must access.
Restrict permissions to the necessary actions, systems, and duration.
Use dynamically issued or time-limited access where supported, rather than granting permanent privileges.
Review the combined permissions available across connected systems to identify access that extends beyond an identity’s intended purpose, particularly for agents that chain access across several systems.
Document exceptions and establish when they must be reviewed or removed.

Outputs

Risk-based access policies, clearly defined permission boundaries, controlled credentials, and documented exceptions with agreed review or expiry dates.

Workstream 4

Monitoring

Signals to investigate

Logs that record authentication but provide little visibility into subsequent actions.
Security alerts that arrive after an automated task has completed.
No baseline of expected behavior to compare activity against.
Activity that cannot be traced back to the purpose or delegated authority behind it.

Actions

Establish a baseline of expected behavior for each identity, monitoring actions and outcomes for agents whose path can vary.
Monitor identity activity against its approved purpose and expected behavior.
Capture sufficient information to establish what actions were performed, which systems were accessed, and under what authority permission was given.
Send relevant alerts and supporting evidence to the security operations team.
Use monitoring findings to inform future risk assessments, access reviews, and policy changes.

Outputs

Reliable activity records, baselines of expected behavior, evidence for audits and investigations, and an ongoing process for improving security controls.

Workstream 5

Revocation

Signals to investigate

No reliable method to stop an agent or revoke its credentials.
Inactive identities that continue to retain access.
Permissions that remain available after the task, project, or engagement they were granted for has ended.
Revocation that disables an account but leaves credentials or tokens valid in connected systems.

Actions

Define the activity or risk thresholds that should trigger security intervention.
Automate account suspension, credential invalidation, or permission removal where immediate action is required.
Withdraw access when an identity’s purpose ends, using the suspension and removal triggers defined through lifecycle ownership.
Confirm that revocation takes effect across every connected system, including dependent credentials and active sessions.
Test containment and revocation procedures before they are needed, including the ability to stop an agent mid-task.

Outputs

Defined and tested procedures for stopping unauthorized access, and confirmation that authority is fully withdrawn when an identity’s purpose ends or its behavior falls outside policy.

04. Putting the governance model into practice

A five-stage process for building control in order of risk

Putting effective NHI governance in place means knowing both the capabilities and processes your organization needs and where to begin. The five stages below show how to build it in a way that fits your business.

None of this requires waiting for an enterprise-wide inventory or redesigning every control at once. Begin in the environments where privilege, reach, and business importance make uncertainty most consequential, then expand as the inventory and operating model improve.

Stage 1: Find the identities

Stage 2: Build a useful catalog

Stage 3: Establish ownership and dependencies

Stage 4: Set priorities

Stage 5: Apply and test the controls

Applying the process to different identity types

The NHI governance model and five-stage process apply across all non-human identities, but the detailed work varies by identity type. Discovery begins in different systems, lifecycles operate at different speeds, and the appropriate credential and access controls depend on how the identity works.

The table below translates the process into practical guidance, showing where to look, what context to establish, and where to focus controls for each identity type.

Identity type	Where to look	What to establish	Control focus
Service and application accounts	Directories, application configurations, databases, infrastructure, and PAM discovery reports.	The application or service supported, access held, dependencies, owner, and last observed use.	Vault and rotate credentials. Remove stale access. Test dependencies before making changes.
API keys, secrets, and certificates	Source code, scripts, CI/CD pipelines, cloud configurations, and developer tools.	Where the credential is called, what it reaches, its privilege, owner, and rotation status.	Remove hard-coded credentials. Use managed vault calls. Automate rotation without breaking connected services.
RPA bots and scripts	RPA platforms, automation workflows, scripts, and connected application accounts.	The business process, systems and data used, permissions, and responsible team.	Tie the identity to the process owner. Review access when the workflow changes. Monitor the actions performed.
Cloud and workload identities	Cloud identity services, containers, Kubernetes, and DevOps platforms.	How the identity is created, its runtime attributes, resources accessed, lifetime, and owner.	Use short-lived credentials and just-in-time access. Limit permissions to the workload. Record runtime activity.
AI agents	AI platforms, agent configurations, integrations, and activity logs.	The agent’s purpose, delegated authority, systems and data in scope, owner, and expected behavior.	Use narrow, time-limited permissions. Monitor behavior and outcomes. Define how access can be stopped immediately.

05. Using the governance model in SAP

Securing non-human identities as SAP moves toward the Autonomous Enterprise

SAP environments already depend on a substantial network of technical users, integration accounts, and automated processes, many of which hold permissions capable of affecting critical business operations. Unlike conventional administrative access, the risk these accounts carry is not always obvious from their technical privileges. An integration account that can modify supplier records or execute financial transactions may present considerable business risk despite never being used interactively.

SAP’s vision of the Autonomous Enterprise adds another dimension. As Joule Assistants and AI agents increasingly support, coordinate, and execute business processes, organizations will need to govern not just the identities accessing SAP, but also the authority those identities have to act. This requires SAP-specific access controls to work alongside enterprise IAM and PAM, rather than operating as separate governance processes.

The model applies across three groups of identities that SAP environments depend on: RPA bots, integration and technical accounts, and Joule Assistants and AI agents.

RPA bots often carry out repeatable SAP transactions using technical or application accounts, sometimes with access across several business functions. As automation changes, these accounts can accumulate permissions that are no longer justified, potentially allowing a compromised or incorrectly configured bot to modify sensitive data or execute transactions outside its intended purpose.

Organizations should link each bot to a business process owner, review its SAP roles and authorizations, and check whether its permissions remain appropriate as workflows change. Existing SAP access risk analysis and segregation of duties controls should apply to automated activity as well as human users, with credentials managed through PAM where appropriate.

SAP integrations rely on technical users, communication users, Remote Function Call (RFC) connections, APIs and other credentials to exchange information and execute processes across systems. These identities are often created within individual projects and can be difficult to discover, particularly where SAP Business Technology Platform (BTP) and third-party applications are involved.

Discovery should extend beyond SAP application roles to include RFC and integration accounts, SAP BTP role collections, API credentials and the supporting infrastructure. Teams should establish what each identity can access and which business process depends on it before changing permissions or rotating credentials. SAP-native governance capabilities can provide the application context, while enterprise IAM and PAM help maintain consistent control across the wider environment.

SAP's Autonomous Enterprise vision introduces AI capabilities that can move beyond providing information to initiating actions and coordinating business processes. A Joule Assistant or specialized AI agent may operate across multiple applications, potentially influencing procurement, finance or other sensitive operations.

For example, an agent that recommends a purchase order presents a different risk from one permitted to create or approve it automatically. Organizations therefore need to distinguish between AI operating on behalf of a user and agents acting with their own delegated authority. Each agent should have a defined purpose, an accountable owner, permissions limited to its role, and clear limits on the actions it can perform without human approval.

As these capabilities are introduced, access governance must also account for the underlying business process. SAP’s existing role controls, segregation of duties requirements and approval workflows need to remain effective, while monitoring should make it possible to identify what an agent did, under whose authority, and whether the action stayed within its approved boundaries, so that access can be withdrawn quickly if it did not.

02 — Where SAP GRC 2026 fits

For organizations using SAP GRC, GRC 2026 creates a new set of architecture and migration decisions as SAP moves toward a more connected governance platform.

What changes

SAP GRC 2026 brings capabilities including Access Control, Process Control, Risk Management, Audit Management, Business Integrity Screening, UI Masking, and UI Logging onto a unified HANA based platform

For SAP-centric organizations, this changes more than the underlying technology. Modernization planning should therefore evaluate:

HANA and S/4HANA dependencies

HANA and S/4HANA dependencies, including technical prerequisites and the target architecture.

Migration and conversion requirements

Migration and conversion requirements, including what should be migrated, redesigned, or retired.

Deployment model

Whether an embedded or hub-based deployment best fits the SAP landscape and governance model.

Integrations

Which governance capabilities should remain SAP-native, and where SAP IAG, enterprise IGA, privileged access management, or other platforms should fit.

Integration Flows

How integrations, responsibilities, approvals, and evidence should move between SAP GRC and connected governance and identity platforms.

Control Alignment

Whether existing controls and rulesets still reflect current business processes.

Lifecycle Planning

How maintenance and lifecycle considerations affect the timing and design of modernization.

Digital Improvements

Which capabilities, workflows, and user experiences could be improved through Fiori, automation, analytics, and emerging AI capabilities.

SAP GRC 2026 modernization questions

How does the move to a HANA-based foundation affect the relationship between SAP GRC and SAP S/4HANA?

Should the target architecture use an embedded or hub-based GRC deployment?

What migration or conversion path applies to the current SAP GRC environment?

Which governance capabilities should remain in SAP GRC, and where should SAP IAG, enterprise IGA, or PAM provide complementary capabilities?

Which existing roles, rulesets, workflows, and integrations need to be migrated, redesigned, or retired?

How will access, risk, controls, approvals, and evidence flow between SAP GRC, S/4HANA, identity platforms, and connected applications?

What changes are required to support the target architecture, including integrations, ownership, maintenance, and ongoing governance?

Five questions to answer before choosing

Where is the authoritative identity lifecycle managed?

Where does SAP-specific access risk analysis take place?

Who approves access and accepts residual risk?

Where is the evidence required for audit retained?

How are privileged, emergency, service, and non-human identities governed?

Why is a Good PAM Program So Important?

Customization vs. Simplicity

Evaluate whether your organization needs highly tailored solutions or could benefit from standardizing processes. Customization delivers precision but increases complexity and maintenance costs.

Integration landscape

Complex SAP environments (with 30+ systems) require solutions capable of handling this scale. Verify each solution's capabilities for reading custom SAP tables and available connectors for your applications. Also consider how to balance SAP-specific needs with enterprise-wide identity management requirements.

Business transformation opportunity

Use the IdM migration as a catalyst to break down silos between SAP and enterprise identity management. Consider how process changes could simplify your technical requirements, especially if you're also planning an S/4HANA migration. This decision point presents an opportunity for business process transformation that could simplify technical requirements and reap numerous organization-wide benefits.

Resource requirements

Assess your team's capabilities against solution requirements to identify gaps in technical implementation skills, business process knowledge, and change management expertise. Consider whether partnerships with implementation experts will be necessary to supplement internal resources.

Common migration pitfalls

Prepare for typical obstacles including undocumented customizations, integration complexity, resource constraints, competing priorities, and dependencies on SAP IdM-specific capabilities. Mitigate risks through a phased migration approach with thorough planning, documentation, and robust testing at each stage.

07 — Keep GRC effective after go-live

Modernization needs an operating model that keeps the environment current once the initial project finishes.

Establish a clean baseline by resolving inherited issues and confirming that roles, risk, controls, ownership, and evidence flows work as intended. Then, stay clean by making those activities part of normal operations so that business and technology changes do not gradually reintroduce the problems modernization was intended to solve.

Your operating model checklist

Before go-live, confirm that you have:

Named business owners for risks and controls.

An agreed review cadence for risks, roles, and controls.

Defined ownership for roles and access decisions.

Measures for control effectiveness and operational performance.

A clear support model for the technology and processes.

A process for assessing new systems, business changes, and regulations.

Governance forums with authority to resolve issues.

A route for findings and incidents to feed back into improvement.

Get clean, stay clean

The work doesn't end at go-live. Rather, the focus shifts from resolving inherited issues to keeping the governance model effective as the business changes. The table below shows how each “get clean” activity should translate into an ongoing “stay clean” discipline.

Get clean

Validate risk output and rulesets
Remediate role-level issues
Remove inappropriate user access
Mitigate accepted residual risks
Rationalize control activity
Establish clear ownership
Automate appropriate evidence

Stay clean

Review rulesets as processes change
Govern role creation and change
Run recurring user access reviews
Monitor mitigating controls
Review control effectiveness
Maintain governance forums and escalation
Monitor and improve the process over time

Use AI as a test of your operating model

As AI assistants and agents become involved in SAP processes, organizations need to assess permissions, approvals, monitoring, accountability, and, where appropriate, the accuracy and completeness of outputs.

This includes determining what identities AI agents use, what permissions they can exercise, who is accountable for their actions, and how those actions are logged and reviewed.

If your existing governance process can absorb those changes and update controls accordingly, the operating model is doing what it should.

Can your governance model absorb Al without needing to be redesigned?

06. Your maturity path

A maturity path from fragmented visibility to continuous control

Your organization’s current maturity will shape how you should begin implementing the NHI governance model. Some teams may first need to establish reliable visibility and ownership, while others may be ready to integrate controls, automate monitoring, or strengthen revocation.

The table below describes five maturity levels, the evidence expected at each level, and the immediate priority for moving forward. Compare each relevant business service, environment, or identity population with these descriptions to identify its current level and determine which steps to prioritize first.

Level	What the environment looks like	Evidence to expect	Immediate priority
1 Fragmented	Discovery is reactive. Ownership and purpose are often unknown. Static credentials and standing privileges are common.	Partial account lists, project records, and manual investigation after an issue or audit request.	Establish a baseline across the highest-risk environments.
2 Inventoried	Major identity types and environments are cataloged. Initial owners and risk tiers exist, but coverage or review is inconsistent.	Central inventory, dependency records, ownership assignments, and a prioritized remediation queue.	Close inventory gaps and connect identities to business services and lifecycle events.
3 Controlled	High-risk identities follow defined credential, rotation, approval, and review policies. Standing access is being reduced.	Policy records, rotation history, certification results, exception ownership, and auditable privilege decisions.	Extend controls beyond the highest-risk identities to all identity types, including workloads, pipelines, bots, integrations, and agents.
4 Integrated	Identity and privilege controls operate through automation workflows. Monitoring can trigger recertification, suspension, or revocation.	Pipeline or orchestration integration, time-bound access evidence, action telemetry, and tested containment procedures.	Improve cross-system context and reduce reliance on manual intervention so that response keeps pace with machine-speed activity.
5 Continuous	Access is evaluated in context at the point of action. Persistent privilege is exceptional, and human and machine activity is fully traceable.	Continuous policy decisions, automated attestation, rapid revocation evidence, and full auditability of privileged actions.	Tune policies as behavior, architecture, and business objectives change.

Start building effective NHI governance

Non-human identities now carry much of the access across your enterprise, and AI agents are changing how that access is used. Effective governance begins with the identities that matter most: giving each a defined purpose, an accountable owner, appropriate access, observable activity, and a reliable way to withdraw its authority. Your existing controls and an initial inventory are enough to make a start, and that discipline can extend across the estate as your visibility grows.

Wherever your organization sits on the maturity path, the next step is easier to see with an outside perspective. Our team can help you identify your highest-risk non-human identities, connect IAM and PAM around a shared view of purpose and ownership, and plan how to bring AI agents and SAP automation under the same governance model.

Talk to our team

IGA Maturity Assessment

We evaluate your current identity management practices objectively, and create customized recommendations specific to your organization with a clear roadmap for improvement. This exercise will indicate your transition readiness, and add insight and context to your solution decision process

Learn more

How to Govern Non-Human Identities (NHIs) in the Age of Agentic AI

Read on to navigate

In this guide

01

The non-human majority

02

Where does agentic AI fit, and what makes it different?

03

The NHI governance model

04

Putting the governance model into practice

05

Using the governance model in SAP

06

Your NHI maturity path

01 — What GRC modernization means in practice

What modernization should achieve

Architecture

People and ownership

Controls

Identity and access

Operations

01. The non-human majority

Human lifecycle controls do not scale to machine identities

02. Where does agentic AI fit, and what makes it different?

AI agents behave and use access differently from other NHIs

How does agentic behavior change the risk picture?

Authority can outlive the original decision

Permissions can combine across a chain

Behavior varies with context

Consequences develop at machine speed

Identity and execution become separate governance questions

03. The NHI governance model

How to govern access from its original purpose through use and revocation

Discovery and inventory

Signals to investigate

Actions

Outputs

Lifecycle ownership

Signals to investigate

Actions

Outputs

Least privilege

Signals to investigate

Actions

Outputs

Monitoring

Signals to investigate

Actions

Outputs

Revocation

Signals to investigate

Actions

Outputs

04. Putting the governance model into practice

A five-stage process for building control in order of risk

Stage 1: Find the identities

What you do:

What you produce:

Stage 2: Build a useful catalog

What you do:

What you produce:

Stage 3: Establish ownership and dependencies

What you do:

What you produce:

Stage 4: Set priorities

What you do:

What you produce:

Stage 5: Apply and test the controls

What you do:

What you produce:

Applying the process to different identity types

05. Using the governance model in SAP

Securing non-human identities as SAP moves toward the Autonomous Enterprise

02 — Where SAP GRC 2026 fits

What changes

HANA and S/4HANA dependencies

Migration and conversion requirements

Deployment model

Integrations