An activity is an asynchronous unit of work executed by a worker under orchestration control. It is used for side effects such as sending email, calling external services, or querying databases, and it can be stateful or non-deterministic because the workflow itself remains the source of execution control.
What an activity is in orchestration systems
An activity is the executable work unit that a workflow delegates to a worker when it needs an action outside the workflow engine itself. In practice, it is the place where side effects happen, such as sending a message, calling an API, or reading from a database, while the workflow remains the source of orchestration and decision-making.
How activities differ from workflow logic
The main distinction is control. Workflow code coordinates state, retries, branching, and timing, while the activity performs the task that may be slow, external, or unpredictable. That split keeps orchestration deterministic and lets the engine replay or recover workflow state without re-executing the side effect as part of the workflow history.
Because an activity can be asynchronous, stateful, or non-deterministic, it is better suited to work that depends on external systems or variable runtime conditions. The workflow can still supervise that work, but the activity itself is where external dependencies are touched and where failure handling often becomes visible.
Why activities matter operationally
Activities are the boundary between orchestration and execution, so their design affects latency, reliability, idempotency, and observability. A poorly designed activity can introduce duplicate side effects, slow retries, or hard-to-debug execution gaps even when the workflow definition is sound.
That is why activity timeouts, retry policies, and execution isolation matter. The workflow engine can orchestrate around failure, but it cannot make an unsafe external action safe. The activity contract needs to be clear about what it may do more than once, what it must never do twice, and what it should report back when partial work has already occurred.
Common usage patterns and trade-offs
Activities are commonly used for integrations that should not live inside deterministic workflow code, especially email delivery, payment calls, report generation, and database lookups. They let teams keep orchestration logic compact while pushing side-effecting work into a separate execution path.
The trade-off is that the workflow now depends on the correctness of the worker and the external systems the activity reaches. That means the activity boundary becomes a design decision about resilience and state handling, not just a programming convenience. Good implementations treat the activity as a controlled integration point, not a general-purpose escape hatch.
Risk and Threat Considerations
Activities concentrate the side effects that workflows depend on, so mistakes here can turn a normal orchestration step into duplicate transactions, inconsistent state, or uncontrolled access to external systems. The risk grows when activities call privileged APIs, handle sensitive data, or run with broad execution rights.
Failure mechanism: If the activity is not idempotent, retry logic, worker restarts, or replay-adjacent execution can produce repeated external actions, stale state, or conflicting updates. If the worker is compromised, the attacker may abuse the activity boundary to trigger legitimate-looking actions at scale.
Impact: The result can be data corruption, repeated notifications or transactions, broken audit trails, or unauthorized downstream effects that appear to originate from trusted orchestration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IR-01 — Platform resilience and recovery planning | Activities affect service resilience and recovery when side effects must be retried safely. |
| Recommendation — Design activity workflows so retries, outages, and worker restarts do not create uncontrolled external side effects. | ||
| NIST SP 800-53 Rev 5 | SC-4 — Information in Shared Resources | Activities can expose shared resources and side effects across workflow and worker boundaries. |
| AU-3 — Content of Audit Records | Activities that perform external actions need auditable traces of what was executed and when. | |
| Recommendation — Isolate activity execution paths so shared resources are not exposed to unintended cross-process effects. Log activity invocations, outcomes, and exceptions so side effects can be reconstructed after failure. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Activities require logging to observe side effects, retries, and abnormal execution patterns. |
| Recommendation — Centralize activity logs so repeated execution and failed side effects can be detected quickly. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Activities are an architecture boundary where side effects, determinism, and recovery behavior must be designed safely. |
| Recommendation — Separate deterministic workflow logic from side-effecting activity code and define safe retry behavior. | ||
Practitioner Guidance
Why practitioners should care: The activity boundary is where orchestration meets the real world, so it deserves the same discipline you would apply to any other integration with side effects. Treat each activity as a clearly owned unit with explicit failure semantics, bounded permissions, and a known recovery story.
What to watch for: Look closely at activities that are long-running, externally visible, or capable of changing business state. If an activity can be retried safely only under narrow conditions, that assumption should be documented and tested rather than left implicit.
Related resources from NHI Mgmt Group
- How should security teams monitor AI agent activity without disrupting developers?
- How can SOC teams use identity context to improve response to agent activity?
- What is the difference between activity metrics and risk metrics in IAM?
- How can organisations tell legitimate automation from compromised service account activity?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org