Treat them as delegated non-human identities, not as ordinary customer sessions. Governance should require explicit consent, narrow authorization scope, token binding, and a complete audit record tying each action back to the human principal that approved it.
Why Governing Customer-Resident AI Agents Is Different
AI agents that operate inside customer accounts are not ordinary user sessions, because they can combine delegated authority, tool use, and repeated execution without a human present. Governance has to start from that reality: the agent’s scope, duration, and approval path must be explicit, or the organisation will inherit hidden privilege and unclear accountability. OWASP’s OWASP Top 10 for Agentic Applications 2026 treats excessive autonomy and unsafe tool access as core failure modes, which is exactly why customer-facing agents need tighter controls than standard app logins.
One practical signal is that governance should be built around delegated non-human identity, not around the illusion of a normal customer session. That means consent should be recorded before the agent acts, the permission set should be narrow enough to match the task, and every action should remain attributable to the human principal who authorised it. In practice, many teams only discover the weakness after an agent has already taken an irreversible action under broad access.
How Governance Works in Practice
Good governance starts with defining what the agent is allowed to do, where it may do it, and how long that authority lasts. The most reliable pattern is to issue scoped, revocable tokens or equivalent credentials per customer, per task, and per environment, rather than sharing a standing account across accounts. That reduces blast radius and makes revocation meaningful when the customer withdraws consent or the workflow changes.
A workable operating model usually includes four controls:
- explicit customer consent before the agent is enabled;
- narrow authorisation scope that limits the agent to named actions and objects;
- token binding or similar proof that the credential is being used by the intended agent runtime;
- an immutable audit trail that links each action to the approving human and the resulting system change.
This is where agent governance intersects with broader identity control. NIST’s NIST Cybersecurity Framework 2.0 is useful for structuring governance, monitoring, and response, while the NIST AI Risk Management Framework helps teams formalise accountability, traceability, and oversight for AI-enabled decisioning. For teams that need a threat-centric view of abuse paths, the MITRE ATLAS adversarial AI threat matrix is useful for thinking about misuse, prompt abuse, and operational deception around AI systems.
In customer environments, the key operational question is not whether the agent can act, but whether each act is pre-authorised, bounded, and reviewable. That governance model fails when teams reuse broad human-style session logic for machine-like execution, because the agent can continue to operate after the original human context has expired or become ambiguous.
Common Variations and Edge Cases
Tighter governance often increases friction, so teams have to balance customer convenience against control strength. A short-lived, tightly scoped agent may be safer, but it can also create more renewal prompts, more support overhead, and more exception handling when the workflow spans multiple systems.
Some environments also need a different pattern depending on the action type. Read-only assistance can often tolerate lighter controls than write-access, payment, data export, or administrative actions. Current guidance suggests treating high-impact actions as step-up events, meaning the agent should require renewed consent or a stronger approval path before it can continue.
Another edge case is shared customer ownership. Where a customer account has multiple human administrators, the audit record should show which person approved the agent, which permissions were granted, and whether any later action exceeded that consent. Teams that skip this distinction often end up with logs that prove activity happened, but not who accepted the risk or why. That gap becomes especially problematic when an agent is used across many accounts with different policy expectations.
Risk and Threat Considerations
Customer-resident AI agents create concentrated access risk because one delegated mechanism can perform many actions at speed, across systems, and with a level of persistence that a normal session does not require. The main exposure is privilege overreach, where the agent is allowed to do more than the customer intended, or can continue acting after the original approval context is no longer valid.
Failure mechanism: The risk materialises when a broad token, weak scope boundary, or poor revocation model lets the agent reuse authority beyond the intended task. Attackers and misuse scenarios both benefit from this, because a compromised or over-permissioned agent can turn a single approved workflow into repeated unauthorised actions, and poor attribution makes it harder to tell whether the human approved the act or merely enabled the conditions for it.
Impact: The concrete consequence is customer-account abuse, data exposure, unauthorised changes, and weak accountability during incident review. If the audit chain does not tie actions back to the approving human principal, the organisation cannot prove consent, reconstruct intent, or reliably contain the blast radius.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Excessive Agency | Customer-resident agents can overstep intended delegated action scope. |
| A2 — Unsafe Tool Use | Agents need governed tool access inside customer accounts. | |
| Recommendation — Limit agent actions to the minimum task scope and require step-up approval for high-impact operations. Restrict tool permissions and validate every tool invocation against approved policy. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Lifecycle and Governance | Delegated agent authority requires explicit lifecycle control and revocation. |
| Recommendation — Issue, scope, rotate, and revoke each agent identity with customer-specific governance. | ||
| NIST CSF 2.0 | GV.OC-01 — Organisational Context | Customer-agent governance depends on defined ownership and accountability. |
| PR.AA-01 — Identity Management, Authentication and Access Control | Agent access must be scoped, authenticated, and attributable. | |
| DE.CM-08 — Monitoring for Unauthorized Activity | Auditability is essential for detecting misuse in customer accounts. | |
| Recommendation — Define ownership, approval boundaries, and accountabilities for agent actions. Enforce least-privilege access and strong authentication for each delegated agent. Log and monitor all agent actions so unauthorized activity is traceable. | ||
| NIST AI RMF | MAP-1 — Map AI Context and Risks | Agent governance needs explicit mapping of purpose, authority, and impact. |
| GOV-3 — Accountability and Governance | Human approval and auditability are core governance needs for delegated agents. | |
| Recommendation — Document the agent’s purpose, allowed actions, and risk boundaries before deployment. Assign clear human accountability for each agent and retain approval evidence. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Overbroad agent privileges can be abused to alter account state. |
| T1528 — Steal Application Access Token | Bound tokens and revocation are central when agents act in customer accounts. | |
| Recommendation — Hunt for and block suspicious account changes made through delegated automation. Protect and monitor tokens used by agents to prevent account abuse and reuse. | ||
Practitioner Guidance
What to prioritise: Put approval boundaries ahead of automation breadth. If the agent can modify data, trigger transactions, or access sensitive customer objects, treat that as a governed privilege decision rather than a product feature.
What to verify: Confirm that every action is attributable to a specific human approver, every credential is scoped to a customer and task, and revocation actually stops the agent from acting immediately. If any of those three fail, the governance model is incomplete.
Decision rule: If the proposed agent can outlive the original workflow context, require stronger consent renewal, shorter token lifetimes, and stricter logging before launch. If it cannot be revoked cleanly, do not treat it as safely delegated.
Practitioner takeaway: The safest operating model is not “an AI agent with customer access”, but a tightly bounded delegated actor whose authority is explicit, temporary, and provable after the fact.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
