What should organisations do when AI agents begin sharing access workflows with human users and service accounts?

Organisations should define AI agents as governed identities, not informal automations. That means assigning ownership, scoping access tightly, reviewing delegation paths, and setting lifecycle controls for provisioning and revocation. If an agent can act, delegate, or chain requests, it needs policy boundaries and monitoring comparable to other high-risk identities.

Why This Matters for Security Teams

When AI agents start sharing access workflows with people and service accounts, the identity model stops being tidy. A human user has intent, a service account has a bounded workload, and an agent can do both: request access, chain tools, delegate actions, and continue operating after the original task has changed. That makes static role design, ad hoc approvals, and shared vault habits dangerous because the access path is now dynamic rather than predictable.

This is where organisations need to treat agents as governed identities, not informal automation. The risk is not just overpermissioning; it is also audit failure, weak ownership, and unclear delegation boundaries. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward runtime governance, not just pre-approved access lists. NHIMG has also documented how quickly exposed AI-related credentials are abused in practice, including the CoPhish OAuth Token Theft via Copilot Studio case and the Amazon Q AI Coding Agent Compromised analysis.

In practice, many security teams only discover the control gap after an agent has already inherited human-style access paths and begun using them in ways nobody explicitly approved.

How It Works in Practice

The practical response is to separate identity, authorisation, and delegation for each actor in the workflow. An agent should have a unique workload identity, a clear business owner, and policy boundaries that describe what it may do at runtime. That means replacing broad shared access with task-scoped entitlement, ideally issued just in time and revoked when the task ends. For autonomous systems, long-lived credentials are a liability because the access pattern is not stable.

Security teams should map each shared workflow to one of three paths: human action, service automation, or agentic action. If an AI agent is participating, then approvals should be tied to the actual operation being attempted, not just to the ticket category or the role that launched the task. This is why intent-based or context-aware authorisation is gaining attention. Policies are evaluated at request time, using context such as task scope, data sensitivity, environment, and whether the agent is attempting a first-time delegation.

• Issue short-lived credentials per task, not standing access for the agent’s lifetime.
• Use workload identity for proof of what the agent is, not a shared human credential.
• Record who approved the delegation path, and to which downstream systems.
• Monitor tool chaining, lateral movement, and repeated access escalation attempts.

Controls such as policy-as-code, just-in-time provisioning, and runtime logging align well with the control direction described in OWASP Non-Human Identity Top 10 and with the broader agentic threat modelling approach in CSA MAESTRO agentic AI threat modeling framework. NHIMG’s OWASP NHI Top 10 coverage also shows why this matters when agent workflows intersect with secrets and delegated tokens.

These controls tend to break down when agents are allowed to reuse human service tickets, because the approval record no longer matches the actual runtime behaviour.

Common Variations and Edge Cases

Tighter access controls often increase operational overhead, requiring organisations to balance automation speed against auditability and blast-radius reduction. That tradeoff becomes sharper when agents sit inside developer tooling, support workflows, or customer-facing operations, where staff expect frictionless handoffs and rapid retries.

Best practice is evolving for a few edge cases. There is no universal standard yet for whether an agent that only drafts actions, but does not execute them, should follow the same control path as an agent that can directly invoke tools. Many organisations treat read-only analysis agents differently from action-taking agents, but that distinction can disappear if the same model later gains write permissions or delegation capability. The safer rule is to classify by maximum reachable privilege, not current intent.

Another common issue is mixed workflows, where a human starts an approval flow and an agent completes the downstream work. In those cases, shared audit trails must show where human intent ended and agent execution began. Otherwise, incident responders cannot reconstruct whether the exposure came from a user, a service account, or the agent itself. NHIMG’s The State of Secrets in AppSec research is a useful reminder that secrets sprawl and long remediation windows amplify this problem. For organisations with federated teams, the governance answer is usually to standardise workload identity, require explicit delegation approvals, and revoke inherited access whenever an agent changes purpose.

Related resources from NHI Mgmt Group

• How can organisations govern AI agents that use service accounts and tokens?
• Why do service accounts and AI agents need different controls from human users?
• Should organisations use JIT access for service accounts and AI agents?
• What breaks when AI agents inherit access from users and service accounts?