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.
How Activity Fits Into Workflow Execution
An activity is the part of a workflow that actually performs external work, while the workflow itself stays in control of orchestration and decision-making. That separation matters because it lets the system pause, retry, fan out, or resume without losing the workflow state or duplicating control logic.
In practice, activities are where side effects happen, such as sending notifications, writing to a database, or calling an external API. Because those actions may be slow, fail independently, or produce non-deterministic results, the activity boundary protects the deterministic workflow layer from becoming brittle.
When teams misunderstand this boundary, they often put orchestration logic, retries, or state management into the wrong layer. The result is usually harder recovery, less predictable execution, and workflows that are difficult to reason about under failure.
Why Activities Matter for Reliability and Side Effects
Activities exist to isolate work that cannot be safely treated as pure, repeatable control flow. They are the mechanism you use when the workflow needs to trigger something real outside the orchestration engine, especially when that work may take time or depend on external systems.
This makes the activity model useful for resilience. A workflow can record progress, schedule the activity, and then recover cleanly if the worker crashes, the network drops, or the downstream service times out. The orchestration layer preserves intent, while the activity handles the operational reality of execution.
That same design also introduces discipline. Activities should be small enough to retry safely and clear enough that their side effects are understandable. If an activity tries to do too much, the workflow becomes harder to observe and the retry model becomes more expensive to operate.
How Activities Differ From Workflow Logic
The workflow is the source of execution control, meaning it decides what should happen and when. The activity is the worker-executed unit that carries out the action. This separation is what allows deterministic workflow code to remain stable even when the underlying work is asynchronous or stateful.
That distinction also explains why activities can be non-deterministic. They may query live data, contact APIs, or use current system state, all of which can change between attempts. The workflow should not depend on those variations for its own correctness; instead, it should treat the activity result as an input to the next controlled step.
For readers who want adjacent implementation context, orchestration systems often pair this model with reliable retry and task execution patterns. General control and secrets handling guidance can be useful when activities call external systems, as NIST SP 800-53 Rev 5 Security and Privacy Controls and OWASP Cheat Sheet Series both reinforce disciplined control of access, execution, and session handling.
Design Considerations for Activity-Based Systems
The main design question is not whether to use activities, but how much responsibility to place inside each one. A well-formed activity has a narrow purpose, a clear input and output contract, and an execution profile that matches the orchestration engine’s retry and timeout behaviour.
Activities also need careful interface design because they frequently become the seam between internal workflow logic and external dependencies. If that seam is vague, teams end up with duplicated logic, hidden coupling, or uncontrolled side effects that are difficult to observe during incidents.
From an architecture perspective, the value of activities is that they create a controlled boundary around operational work. The workflow stays predictable, the worker can evolve independently, and the system can absorb transient failures without collapsing the whole process.
Risk and Threat Considerations
Activities are attractive failure points because they often sit closest to external systems, sensitive data, and real-world side effects. If an activity is invoked repeatedly, redirected, or given malformed inputs, the result can be duplicate actions, data corruption, unintended outbound calls, or exposure through a compromised integration path.
Failure mechanism: Weak idempotency, poor timeout handling, or unsafe retry behaviour can turn a transient error into repeated side effects, while overly broad activity permissions can expand the blast radius of a compromise.
Impact: The likely outcome is operational inconsistency, data integrity loss, and broader security exposure when a malicious or faulty activity path can trigger external actions more than once or in the wrong context.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | Activities often call external systems and need tightly managed access to reduce blast radius. |
| Recommendation — Restrict activity permissions to the minimum access needed for each external action. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Activity workers rely on controlled access when executing side-effecting operations. |
| RS.CO — Communications | Workflow and activity boundaries depend on reliable operational communication during failures and retries. | |
| Recommendation — Apply PR.AC controls to constrain what activity workers can access and invoke. Define clear execution and failure communications between orchestrator and worker paths. | ||
| OWASP Agentic AI Top 10 | A1 — Identity and Access Abuse | Side-effecting execution paths can be abused when delegated action authority is too broad. |
| Recommendation — Limit delegated action scope for workers that execute external side effects. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets Exposure | Activities commonly depend on credentials or tokens to reach downstream services. |
| Recommendation — Store and rotate activity credentials so downstream calls do not depend on exposed secrets. | ||
Practitioner Guidance
What to watch for: The most common operational mistake is treating an activity like ordinary helper code. Activities deserve explicit ownership, clear retry semantics, and a conscious boundary around side effects so that orchestration logic remains deterministic.
Practitioner takeaway: If a unit of work can fail independently or produce external effects, model it as an activity rather than letting it leak into workflow control flow.
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?
