A delegated web action is a machine-performed task that changes state on a website or web application on behalf of an organisation. It goes beyond retrieval because the identity is not just reading information. The governance issue is who authorised the action, what scope applied, and how the session was traced.
Expanded Definition
Delegated web action sits between ordinary browsing and full automation: an NHI, service account, or AI Agent is authorised to perform a state-changing task on a website or web application on behalf of an organisation. That might include submitting a form, approving a workflow, updating a record, or triggering a transaction. The important distinction is not the interface, but the governance around the action: who granted authority, what scope was allowed, whether the session was time bound, and how the activity was attributable after the fact.
Usage in the industry is still evolving. Some teams treat delegated web action as a browser-based extension of API delegation, while others classify it as agentic execution with human approval checkpoints. The nearest control thinking comes from NIST Cybersecurity Framework 2.0, especially identity, access, and auditability outcomes, but no single standard governs this term yet.
The most common misapplication is assuming that a logged-in session equals delegated authority, which occurs when organisations fail to bind the action to a specific identity, scope, and expiry.
Examples and Use Cases
Implementing delegated web action rigorously often introduces operational friction, because every permitted action needs tighter scoping, stronger traceability, and clearer approval paths, requiring organisations to weigh automation speed against loss-containment and accountability.
- An AI Agent opens a supplier portal, updates delivery dates, and records the change under a short-lived delegated token rather than a shared credential.
- A finance workflow bot submits invoice approvals in a web app after a human authorises the role, with each step traced to the originating NHI governance policy.
- A customer support automation updates account details through a browser session, but only within a narrowly defined task scope and a JIT window.
- A third-party service completes portal-based actions for a client, where audit evidence is retained to show who delegated access and when it expired. This is closely tied to the lifecycle and offboarding concerns described in the Ultimate Guide to NHIs.
- A security team uses delegated web action for remediation tasks such as disabling an exposed account, but constrains the session so the agent cannot pivot beyond the approved target system.
These patterns also map to broader identity governance expectations in NIST Cybersecurity Framework 2.0, especially when organisations need to demonstrate control over who can act, not just who can view.
Why It Matters in NHI Security
Delegated web action becomes a security issue whenever organisations allow machine actors to perform human-like tasks without equivalent controls. If the action is not tied to a clearly authorised NHI, scope creep is easy: a workflow bot that was meant to submit a single request can end up modifying records, approving transactions, or accessing adjacent systems. That is why delegated action should be treated as a privileged activity, not a convenience feature.
This matters in practice because NHI exposure is often invisible until something breaks. NHIMG research shows that Ultimate Guide to NHIs reports only 5.7% of organisations have full visibility into their service accounts, which means delegated sessions can be difficult to trace after misuse, compromise, or accidental overreach. The right response is to combine short-lived authorisation, least privilege, and immutable logging so the action can be explained later to auditors and incident responders. Those controls align with the governance expectations implied by NIST Cybersecurity Framework 2.0.
Organisations typically encounter the need to formalise delegated web action only after a portal-based change causes fraud, data corruption, or an untraceable admin event, at which point the term becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Delegated actions depend on strong identity scoping and traceable non-human authority. |
| NIST CSF 2.0 | PR.AA | Identity and access governance applies to machine-performed state-changing web actions. |
| NIST Zero Trust (SP 800-207) | Zero Trust treats every delegated session as continuously verified, not implicitly trusted. |
Classify delegated web action as a controlled access event and require approval, logging, and review.
