Orchestration & Agentic Security · High-Impact Action Approval and Irreversibility Controls
Limit how the agent can change itself
Verify that any self-modification capability (e.g., prompt rewriting, tool-list changes, parameter updates) is restricted by boundaries that are enforced by the runtime and cannot be changed or bypassed by the agent.
OWASP AISVS v1.01, requirement 9.2.5
In plain English
Some agents can rewrite their own prompts, change their tool lists or tune their own settings. If yours can, put hard limits on that from outside the agent. Otherwise one successful injection can become permanent, or the agent can grant itself new powers.
What good looks like
- Self-modification is disabled, or limited to a written list of permitted changes.
- The limits are enforced by the runtime and stored where the agent cannot write.
- The agent cannot add tools, widen permissions or change its safety instructions.
- Every self-change is logged and can be reviewed and undone.
How teams usually do it
- Load system prompts, tool lists and permissions from read-only configuration deployed through your normal change process.
- Where self-tuning is wanted, let the agent propose changes that a person or pipeline approves.
- Keep agent-editable notes or memory apart from instructions, and never load them into the system role.
Suggested evidence
- Permissions on the configuration stores.
- Logs of attempted and accepted self-changes.
- A test where the agent tries to add a tool and is refused.
Common mistakes
- Storing the agent's instructions in a memory store it can write to.
- A coding agent with write access to its own configuration, rules or hook files.
- Letting the agent install new tools or plugins on request.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.