Accountability should follow the owning identity, the approved application owner, and the control owner for the permissions in play. If the assistant is using a user token, the human may be visible in logs, but the governance issue is still the delegated system and the team that approved its access.
Why This Matters for Security Teams
Accountability becomes murky the moment an assistant can act with delegated authority, because logs may show a human user while the actual risk sits in the application, the workload identity, and the control owner who approved access. That is why NHI governance matters here. NHIs often outnumber human identities by 25x to 50x in modern enterprises, and visibility is still weak: only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
For security teams, this is not just an audit question. It affects incident response, privileged access reviews, segregation of duties, and whether an assistant is operating inside the approved trust boundary or simply inheriting a user’s authority. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls still places responsibility on the organisation to govern access, monitor use, and enforce accountability even when actions are delegated. In practice, many security teams discover this only after an assistant has already completed an unauthorized workflow under a legitimate user session, rather than through intentional governance design.
How It Works in Practice
The practical answer is to treat the assistant as a governed non-human actor, not as a passive extension of the person using it. Accountability should be split across three layers: the human requester, the application owner that enabled the assistant, and the control owner who approved the permissions and policy. That separation matters because the assistant may chain tools, call APIs, or take actions the user never explicitly intended.
In mature implementations, the assistant should use workload identity and short-lived credentials rather than standing tokens. The runtime should evaluate each action against policy at request time, using context such as task, resource, environment, confidence, and risk. That approach aligns with least privilege and reduces the chance that a user token becomes a permanent capability. The Ultimate Guide to NHIs underscores why this matters: 97% of NHIs carry excessive privileges, which is exactly the condition that turns delegated assistance into broad, hard-to-trace authority.
- Assign an owning service or application to every assistant that can take action.
- Use ephemeral credentials with tight TTLs and clear revocation paths.
- Require policy checks before each sensitive tool call or transaction.
- Log both the human initiator and the non-human identity used to execute the action.
- Map approval, review, and exception handling to named control owners.
This is consistent with NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects organisations to define accountability, authorization, and auditability rather than relying on implied intent. These controls tend to break down when assistants inherit broad workspace permissions in multi-tenant SaaS environments because the system can execute approved-looking actions across multiple data domains without a clear boundary.
Common Variations and Edge Cases
Tighter delegation often increases operational overhead, requiring organisations to balance speed and autonomy against traceability and control. That tradeoff is especially visible when an assistant acts through a shared service account, an orchestration layer, or a platform-admin session. In those cases, the human may be visible in audit logs, but the accountable party is still the team that provisioned the access path and the owner who accepted the residual risk.
There is no universal standard for this yet in agentic workflows, but current guidance suggests the most defensible model is to treat the assistant as a separate governed identity with its own policy, telemetry, and offboarding process. When a user token is reused for convenience, the organisation should still preserve attribution for both the request and the execution path, because responsibility for the action does not transfer to the assistant. If you need a broader governance frame, the Ultimate Guide to NHIs is useful for lifecycle and access control expectations, while NIST SP 800-53 Rev 5 Security and Privacy Controls remains the baseline for assigning accountable owners to access and monitoring duties.
Edge cases arise when multiple teams can modify the assistant, when third-party plugins expand its authority, or when approvals are embedded in product UX rather than security workflows. In those environments, accountability often fractures unless ownership is written into policy and incident procedures before deployment.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Assistant access should be governed as a non-human identity with explicit ownership. |
| OWASP Agentic AI Top 10 | A-02 | Agents acting on behalf of users need runtime control and clear accountability. |
| CSA MAESTRO | IAM-02 | MAESTRO addresses agent identity, delegation, and control ownership in autonomous workflows. |
| NIST AI RMF | AI RMF governance applies to accountability, oversight, and traceability for AI actions. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access governance are central when assistants act for users. |
Assign each assistant a named owner and document its identity, permissions, and offboarding path.
