Identity, security, and platform teams should share ownership, but accountability must be explicit and tied to the workflow owner. Shared workflows collapse responsibility quickly unless each action can be traced to a specific identity and authority chain. That is especially true when agents operate inside developer or browser environments.
Why This Matters for Security Teams
Shared workflows fail when governance is split by org chart instead of by execution path. Human users still fit familiar controls such as RBAC and ticketed approvals, but agents act with delegated authority, can chain tools, and may trigger actions no one reviewed in advance. That makes ownership unclear unless the workflow owner is accountable for both the human step and the machine step.
The risk is not theoretical. The State of Non-Human Identity Security shows that visibility and control gaps remain common, with only 1.5 out of 10 organisations highly confident in securing NHIs. For workflows that mix people and agents, that confidence gap turns into audit failure, over-privileged access, and delayed incident response. Current guidance from the NIST AI Risk Management Framework is to assign accountability where decisions are made and where risk is introduced, not where identity happens to sit in a directory.
In practice, many security teams encounter ownership drift only after an agent has already approved, modified, or exfiltrated data through a workflow that no single team can fully explain.
How It Works in Practice
Effective governance starts by treating the workflow as the unit of control. The human user owns the business intent, the platform owner owns the execution environment, and the security team owns policy design, monitoring, and exception handling. That division works only when each step is mapped to a specific identity and authority chain, including the agent’s workload identity and the human’s delegated approval path.
For agents, static access models are usually too blunt. Best practice is evolving toward runtime authorization, where the system checks what the agent is trying to do, with which tool, on which data, and under what constraints. That is why emerging patterns such as intent-aware policy, ephemeral credentials, and short-lived secrets matter more than one-time provisioning. The OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework both reflect the same operational reality: agent behaviour is dynamic, so governance must be evaluated at request time, not only at onboarding.
Practically, strong programs use three controls together:
- Workload identity for the agent, so the system knows what the agent is cryptographically and not just what secret it holds.
- Just-in-time privilege for the task, so credentials expire as soon as the action completes.
- Policy-as-code for runtime decisions, so approvals and denials are consistent and auditable.
That model aligns with lessons in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and with the failure patterns documented in AI LLM hijack breach. These controls tend to break down when agents are embedded in browser automation or developer environments because the identity boundary becomes invisible and the human assumes the tool is still acting under direct supervision.
Common Variations and Edge Cases
Tighter governance often increases coordination overhead, requiring organisations to balance faster delivery against clearer accountability. That tradeoff becomes visible in shared environments where developers, operations staff, and agents all touch the same workflow. There is no universal standard for this yet, so current guidance suggests making ownership explicit at the workflow level and using exception paths for high-risk actions rather than trying to force one team to own everything.
One common edge case is partial autonomy. A human may initiate the task, but an agent completes it across multiple tools. In that model, the human owner is still accountable for the request, while the platform and security teams govern the guardrails that prevent privilege creep. Another edge case is vendor-hosted agentic tooling, where the organisation can define policy but may not control the internal agent runtime. In those cases, document the trust boundary clearly and require evidence of short-lived credentials, logging, and revocation.
Security teams should also watch for environments where secrets are reused across both humans and agents. The State of Secrets in AppSec shows how fragmented secrets management can undermine control, especially when workflows span code, browser sessions, and automated tools. In edge cases, the safest approach is often to constrain the agent’s scope to narrowly defined actions and require human approval for any step that changes data, permissions, or external side effects.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AA1 | Covers governance risks in shared human-agent workflows and tool chaining. |
| CSA MAESTRO | GOV-1 | Addresses accountability and control mapping for agentic AI operating models. |
| NIST AI RMF | Supports governance, accountability, and measurable AI risk management. |
Assign runtime policy checks and explicit ownership for every agent action that crosses trust boundaries.
