LISTEN TO THIS ARTICLE

Consent and delegation boundaries are becoming a real product constraint for AI agents: users are being asked to authorise systems that can plan, delegate, and act beyond the screen where consent was first given. The January 2025 paper Authenticated Delegation and Authorized AI Agents frames the technical gap directly: agents need authenticated, authorised, and auditable delegation so humans can restrict scope while preserving accountability.

Evidence base: source trail below.

This sits beside AI Safety, Evals & Guardrails, runtime policy enforcement for AI agents, and agent accountability becoming runtime infrastructure. Consent is not a banner. It is a boundary that should survive tool calls, sub-agent handoffs, retries, memory writes, and policy exceptions.

Key takeaways

  • Agent consent should specify task, data, tools, time, delegation rights, and approval triggers.
  • Delegation should carry the user's authority only as a scoped, revocable token, not as a vague instruction.
  • High-impact actions need renewed consent at the action boundary, not only at session start.
  • Audit logs should record consent state and delegation chain without copying sensitive content.

The answer is pre-defined authority plus fresh approval at material boundaries.

Most consent UX was built for static access. OWASP's excessive-agency risk covers LLM systems that gain too much functionality, permission, or autonomy, including agents that use extensions and downstream systems in response to prompts OWASP LLM06: Excessive Agency.

That is why consent for agents should be structured like a runtime policy object. The user is not consenting to "help me with my inbox". The grant can limit reads to named labels, replies to unsent drafts, memory to no writes, and external contact to approval-gated actions.

The counterargument is that granular consent makes products unusable. That is true if every action becomes a modal. CoSAI's July 2025 secure-by-design principles warn that relying on human intervention for every step can create control fatigue and weak security theatre CoSAI secure-by-design agentic systems. The answer is pre-defined authority plus fresh approval at material boundaries.

Delegation boundaries AI agents should carry forward

Delegation is the hard part. A user may authorise an agent to book travel, and the agent may call a flight-search tool, a payment tool, a calendar tool, and a second agent that handles policy checks. The CoSAI IAM model treats those handoffs as enforceable identity and authorisation events, not private reasoning steps Agentic Identity and Access Management.

The Authenticated Delegation and Authorized AI Agents paper proposes extending OAuth 2.0 and OpenID Connect with agent-specific credentials and metadata, and it also proposes translating natural-language permissions into auditable access-control configurations. "Tyler asked me to handle this" is not an authorisation model. The model needs a delegated authority record with subject, purpose, resources, expiry, tool scope, delegation depth, and revocation path.

CoSAI's March 2026 agentic IAM paper is stricter: it says agents should be treated as first-class identities, should avoid standing privilege, should separate agent rights from on-behalf-of rights, and should enforce authentication and authorisation at each hop and final tool endpoint Agentic Identity and Access Management. That is the operational version of consent. The agent does not inherit the whole human account. It gets a task-limited credential that can be checked every time it tries to act.

For builders, this is where the accountability gap when AI agents act meets implementation. If you cannot tell whether a tool call came from the user, the primary agent, a delegated sub-agent, or a retry path after denial, you have a chat transcript, not a consent boundary.

Some boundaries are obvious: money movement, deletion, external communication, code execution, data export, credential access, contract changes, medical advice, hiring decisions, regulated workflows.

Initial consent should not cover every later action. Some boundaries are obvious: money movement, deletion, external communication, code execution, data export, credential access, contract changes, medical advice, hiring decisions, regulated workflows. Others are contextual: one support ticket is not the same grant as every support ticket in an account.

Article 14 of the EU AI Act points towards consent that can be acted on during operation because it says high-risk AI systems should enable human oversight proportionate to risk, autonomy, and context, including the ability to monitor, override, reverse, intervene, or stop the system EU AI Act Article 14.

For agents, disclosure is only the start. Article 14's monitor, override, reverse, intervene, and stop controls are closer to the right product shape because consent has to attach to the actions the system may take EU AI Act Article 14.

Consent that cannot be reconstructed is not much use after an incident. Article 12 of the EU AI Act says high-risk systems should technically allow automatic event logs over their lifetime, and Article 26 says deployers of high-risk systems should keep logs under their control for at least six months unless other law says otherwise EU AI Act Article 12 EU AI Act Article 26.

NIST's Generative AI Profile recommends policies and procedures that define roles and responsibilities for human-AI configurations and oversight, and it recommends acceptable-use policies for generative AI interfaces and decision-making tasks NIST AI 600-1. If the approval, authority scope, user identity, agent identity, tool call, data class, and escalation reason are not recorded, the organisation cannot prove what was authorised.

The audit trail should not become a data leak. Store consent state, authority handles, policy version, decision reason, data labels, tool names, timestamps, and review events. Avoid copying raw prompts, secrets, credentials, or full document bodies into broad audit stores. For the security side, the AI agent security playbook covers why agent logs need the same containment thinking as the agent itself.

Operator takeaway

Treat consent as a runtime contract, not a checkbox. Before an agent acts for a user, define the task, data, tools, duration, allowed side effects, delegation depth, memory rights, approval triggers, and revocation route. Then enforce those fields at tool time. If a sub-agent cannot receive the same scoped authority record and a high-risk tool cannot check it, the delegated-action design conflicts with CoSAI's requirement to enforce authorisation at each hop and final tool endpoint Agentic Identity and Access Management.

Source trail

Research papers

Security and identity standards

Legal and policy sources

Related Swarm Signal analysis