An always-on agent is a software identity that continues operating beyond a single user session. In identity terms, it behaves more like a persistent workload or service account than a chat assistant, because it can retain context, use connectors and keep taking actions between interactions.
What Makes an Always-on Agent Different
An always-on agent is not just a conversational interface that wakes up when a person types. It is a persistent software identity that can keep state, retain context and continue acting across sessions, which makes it operationally closer to a service account than a short-lived assistant.
That persistence changes the security model. The question is no longer only what the agent can do in one interaction, but what it can continue doing after the original user is absent, the original context has aged, or the original business need has changed.
Why Persistence Changes the Security Model
Persistent operation expands the time window in which trust can be abused. A long-lived agent may hold tokens, connector grants, cached context or delegated permissions that outlive the moment they were approved, so the security concern is often less about a single action and more about ongoing authority.
That is why always-on agents should be evaluated as runtime actors with continuing access, not as transient prompts. Their risk profile grows when authority is broad, when the agent can chain actions, or when it can operate without fresh human confirmation for sensitive steps.
NHIMG’s AI Agent Authorisation Guide is useful here because it frames per-action decisions, task-scoped access and approval gates as the right response to persistent agent authority.
Lifecycle, Context and Connector Exposure
Always-on agents accumulate operational risk through their lifecycle, not just their initial setup. Retained context can become stale, connector permissions can drift, and the agent may continue to act on outdated assumptions long after the original request is no longer valid.
The most important exposure is often not the model itself, but what the agent can reach through connectors, APIs and other delegated integrations. Once those links exist, persistence turns a convenient workflow into a standing pathway into business systems.
NHIMG’s Agentic AI Identity Guide explains how agent identity, delegation and retirement fit into that lifecycle, while the Shadow AI and AI Agent Discovery Guide helps organisations find unmanaged agents and connector grants that have escaped normal governance.
Detection, Oversight and Recovery
Because an always-on agent can keep working between human interactions, security teams need visibility into its actions, not just its prompts. Good monitoring focuses on attribution, unusual action sequences, connector use, privilege changes and signs that the agent is acting outside expected business patterns.
Recovery also matters more than in a normal chat session. If the agent misbehaves, you need a clear way to suspend it, revoke access, review what it touched and decide whether its retained context or credentials can still be trusted.
NHIMG’s AI Agent Observability, Audit and Incident Response Guide is the most directly relevant internal resource for logging, attribution and kill-switch planning.
Risk and Threat Considerations
Always-on agents create a larger compromise window than session-bound assistants because stolen tokens, poisoned context or an abused connector can keep paying dividends after the initial breach. That makes them attractive targets for privilege abuse, persistence and quiet exfiltration.
Failure mechanism: An attacker or malicious prompt can steer a persistent agent into reusing trust, amplifying a one-time compromise into repeated access, hidden action chaining or continued misuse of delegated authority.
Impact: The result can be unauthorized actions, data exposure, connector abuse, account takeover through delegated credentials, or prolonged operational damage before the abuse is noticed.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 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-05 — Overprivileged NHI | Always-on agents can accumulate excessive standing access over time. |
| NHI-01 — Improper Offboarding | Persistent agents require retirement and access removal when no longer needed. | |
| NHI-07 — Long-Lived Secrets | Always-on agents often depend on credentials that outlast a single session. | |
| Recommendation — Limit persistent agent permissions to the minimum scope needed for each task. Define offboarding steps that revoke agent access and disable dormant connectors. Rotate and constrain long-lived secrets used by persistent agents. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Persistent agents act as external or non-person entities that must authenticate reliably. |
| AC-6 — Least Privilege | The core risk is sustained access that can exceed what the task needs. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Always-on agents need reviewable logs to support attribution and incident response. | |
| Recommendation — Authenticate persistent agents with strong, unique credentials and trust bindings. Constrain agent permissions so standing access never exceeds task need. Review agent audit records for abnormal action chains and connector use. | ||
| NIST Zero Trust (SP 800-207) | 3 — Implicit Trust and Explicit Verification | Always-on agents should not retain blanket trust between actions or sessions. |
| Recommendation — Verify the agent and the request before granting each sensitive action. | ||
Practitioner Guidance
Why practitioners should care: The governance question is not whether the agent is helpful, but whether its authority is intentionally bounded over time. Always-on behaviour should trigger explicit ownership for lifecycle, access review and shutdown, because persistent autonomy without a retirement path becomes a control gap.
Practitioner takeaway: Treat the agent like a durable workload with identity, scope and revocation requirements, not like a temporary chat session that can be forgotten after launch.