Yes, unless those features are explicitly governed. Memory and recurring tasks create persistence, which means a single successful injection can survive the original conversation and affect future sessions. Organisations should treat them like high-risk delegated privileges and require approval, scope limits and revocation paths.
Why Memory and Scheduled Actions Change the Risk Model
Memory and scheduled actions are not just convenience features. They give an assistant persistence, which means the assistant can carry state or keep acting after the original prompt is over. That turns a one-time interaction into an ongoing execution surface, so organisations should judge these features by who can write to them, how far they persist, and how quickly they can be revoked.
That persistence matters because a successful injection, mistaken instruction, or overbroad delegation can outlive the conversation that introduced it. If a memory store or recurring task can influence future behaviour without fresh approval, the feature becomes a control boundary, not a productivity add-on.
A practical way to think about the issue is to treat memory as retained authority and scheduled actions as deferred authority. Both can be useful, but both increase the blast radius of a single mistake if scope, retention and execution rights are not tightly bounded.
When Restriction Is the Safer Default
Default restriction is sensible wherever the assistant can reach sensitive tools, customer data, production systems or external communications. In those environments, persistent state can be abused to smuggle instructions forward, and scheduled execution can turn a harmless-looking note into repeated action at scale.
This is why governance should be explicit rather than informal. Organisations should require approval for any memory or recurring task that can affect access, disclosures, spending, approvals or external side effects, and they should define whether the feature is tenant-wide, workspace-scoped, or limited to a single user or workflow.
Where the assistant is handling high-trust work, the better question is not whether memory is useful, but whether the feature is bounded enough that its failure is containable. If the answer is no, restriction is the right control until stronger oversight exists.
What Good Governance Looks Like in Practice
Strong governance makes persistence observable and reversible. That means users should be able to see what the assistant remembers, what recurring actions are scheduled, why those actions exist, and how to delete or revoke them without waiting for vendor support.
Approval should be tied to purpose, not just to the feature itself. A memory item that supports a narrow workflow may be acceptable, while a memory item that stores open-ended preferences, secrets, or cross-project context is much harder to justify. The same applies to scheduled actions: low-risk reminders are very different from automated actions that can trigger tool calls or share data externally.
Organisations should also separate human convenience from machine authority. If the feature can influence future decisions, it needs ownership, review, expiry and logging, otherwise the assistant slowly accumulates hidden agency over time.
Risk and Threat Considerations
Persistent memory and recurring actions expand the attack window because the compromise does not have to happen in the moment the harm occurs. A single prompt injection, poisoned memory entry, or abused scheduling permission can create delayed execution that looks legitimate when it later fires.
Failure mechanism: An attacker or careless user seeds memory or schedules a task that survives the original interaction, then relies on the assistant to reuse that state in a later session or future run. If the system does not force reapproval, the assistant can repeat the bad instruction or action under normal-looking conditions.
Impact: The result can be data leakage, unauthorised tool use, repeated external actions, or privilege abuse that is harder to trace because the harmful instruction was stored earlier and executed later. At scale, this creates a durable control failure rather than a one-time error.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Memory and scheduled actions can preserve or extend delegated authority across sessions. |
| ASI06 — Memory & Context Poisoning | Stored memory can be poisoned and later reused to drive harmful future behaviour. | |
| ASI10 — Rogue Agents | Unbounded recurring actions can let an assistant keep operating beyond intended oversight. | |
| Recommendation — Limit persisted agent authority and require approval before reusing stored permissions or actions. Validate, scope and expire memory that influences later agent decisions. Add revocation, monitoring and hard stops for any agent action that can repeat autonomously. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Persistent actions should be limited to the minimum authority needed for the workflow. |
| AU-2 — Event Logging | Memory changes and scheduled executions need auditability to support detection and rollback. | |
| Recommendation — Constrain stored and scheduled actions to the minimum permissions required. Log creation, modification and execution of persistent agent state. | ||
Practitioner Guidance
What to prioritise: Restrict any memory or scheduled action that can touch production systems, customer data, payments, approvals, or outbound communications. Those are the cases where persistence most clearly changes the security posture.
What to verify: Confirm that users can inspect, edit, expire and revoke stored memory and recurring tasks, and that those actions are logged. If revocation is hard to prove, the control is not mature enough to rely on.
Decision rule: If the assistant can act later without a fresh human decision, treat the feature as delegated privilege and require a narrower scope or explicit approval gate before enabling it.
Practitioner takeaway: Memory and scheduled actions are acceptable only when they are governed as bounded authority, because persistence is what turns a normal assistant into a durable security risk.
Related resources from NHI Mgmt Group
- What are the core risks identified by the OWASP Agentic Top 10?
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
- How should security teams govern machine identity credentials in agentic AI environments?
- Where should practitioners go deeper on agentic application risks?