Any workflow that can read, move, or transform data because an identity has been granted permissions behind it. This includes AI-assisted processes, service accounts, and automated systems. The critical issue is not the tool label, but the access rights and accountability attached to the process.
Expanded Definition
An access-bearing process is any automated or semi-automated workflow that can read, move, modify, or transform data because permissions were granted to the identity behind it. That identity may be a service account, workload credential, pipeline token, or AI-assisted agent. In NHI governance, the decisive factor is not whether the process is called “application” or “AI”, but whether it holds actionable access and can trigger security-relevant outcomes. This makes the term closely related to service account governance, privileged automation, and agentic execution with tool access. The OWASP Non-Human Identity Top 10 describes how these identities become risk-bearing when secrets, entitlements, and runtime access are not managed with the same discipline applied to human identities. Guidance varies across vendors on whether AI agents are treated as workloads, identities, or delegated actors, so the operational question is always the same: what can the process actually do, and who can prove it? The most common misapplication is assuming a process is low risk because it is automated, which occurs when teams ignore the permissions, secrets, and downstream systems attached to it.
For practitioners, the term is useful because it forces access reviews to focus on execution authority rather than tool category. An access-bearing process may have no user interface, no human operator at runtime, and no interactive login, yet still be able to exfiltrate data, alter records, or invoke production services. That makes it a core NHI security object, not a generic application label.
Examples and Use Cases
Implementing access-bearing process controls rigorously often introduces operational friction, requiring organisations to weigh automation speed against tighter entitlement review, secret rotation, and runtime observability.
- A CI/CD pipeline that deploys code to production using a token. If the token can also read secrets, the pipeline is an access-bearing process and should be governed like a privileged workload. See the OWASP Non-Human Identity Top 10 for the underlying risk model.
- An AI agent that can query internal systems, open tickets, and trigger approvals through tool APIs. The agent is access-bearing because its outputs can change state, even when a human prompted it.
- A backup job that copies data between regions using a service account. It may be routine, but the account still needs least privilege, rotation, and monitoring aligned to the lifecycle guidance in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
- An ETL workflow that transforms customer records and writes results to a analytics lake. If the workflow can alter regulated data, it is not just a data job, but an access-bearing process with governance impact.
- A federated workload using SPIFFE-style identity assertions to reach services across trust boundaries. The process remains access-bearing because authentication is tied to machine identity, not a human session.
These cases align with the broader NHI lifecycle described in Ultimate Guide to NHIs, where entitlement scope and credential hygiene determine whether automation is safe or exposed.
Why It Matters in NHI Security
Access-bearing processes matter because they often become the hidden path from a minor credential issue to a major incident. NHIMG reports that 97% of NHIs carry excessive privileges, and that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes over-permissioned automation a primary attack path. When a process can move data or invoke systems, any leaked secret, overbroad role, or unreviewed integration can become an enterprise-wide escalation route. This is why NHI security teams care about process accountability, not just authentication. The security question is whether the process can be explained, bounded, rotated, and revoked with precision. That is also why the OWASP Non-Human Identity Top 10 and the 52 NHI Breaches Analysis are useful reference points: they show how routine automation becomes incident material when identities are invisible or privileged by default. Organisational risk usually becomes obvious only after a pipeline, agent, or service account has already moved data in ways defenders did not expect, at which point access-bearing process controls become operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and privilege misuse in non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege applies to automated processes with data access. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust limits what any process can reach, even after authentication. |
Inventory access-bearing processes and constrain their secrets, scopes, and runtime permissions.
Related resources from NHI Mgmt Group
- What breaks when access reviews are not tied to a lifecycle process?
- What breaks when agent access is managed in a separate governance process?
- Who is accountable when a shared-device access process fails compliance or audit review?
- When does a ticketing process create more access risk than it reduces?
