Stop an AI agent taking an unauthorized action by denying it direct outward write capability and enforcing action rules in a separate execution layer. Require a named human's decision on a specific evidence-backed proposal. Before execution, validate the approved content, target, current permissions, and business state, then record the result and reconcile uncertain outcomes before retrying.
Define the forbidden effect in business terms
A wrong action is not limited to an invalid tool call. A technically valid request can target the wrong record, reach an unintended recipient, or apply a change after the conditions that justified it have disappeared. Define the forbidden effects in terms of the business system.
Consider a hypothetical agent recommending an update to an internal service entitlement. It might select the wrong employee because names match, recommend a permission the reviewer cannot grant, or use stale evidence about the person's role. Each failure can produce a well-formed proposal and a syntactically valid API payload.
Write the conditions under which the action is permitted: resolved identity, eligible target state, authorized reviewer, specific approved content, and an allowed execution route. These conditions belong in enforceable application and integration rules, alongside evaluations of the agent's proposal quality.
Remove alternate outward write paths
CodeDTX's Propose–Decide–Execute pattern gives the agent the ability to write proposals with evidence attached. A named human records a decision, and a separate executor performs approved outward writes. The separation must exist in credentials and tool access, not only in the workflow diagram.
Inspect the agent runtime for general database writers, unrestricted HTTP clients, command execution, or connectors that combine read and write operations. Any available route that can change the destination can bypass a carefully built approval queue if its permissions are broader than the declared workflow.
Expose narrowly defined read contracts to the agent and keep outward write credentials with the executor. The proposal store itself needs a constrained contract so an agent cannot impersonate a reviewer by changing decision fields or set its own proposal to an approved state.
Make approval specific and verifiable
An approval should identify the proposal version, target, and action content the person reviewed. The executor should compare the submitted work with that decision rather than trusting a free-text assertion that approval was obtained. The reviewer must hold the authority required for the action category.
If the proposal changes, check whether the change affects what was approved. Replacing a recipient, expanding the target set, or editing substantive fields creates a different action. Do not let a mutable draft inherit authorization simply because its proposal identifier remains the same.
Record rejections and expirations as states that cannot execute. A model that retries with more persuasive wording should not turn a rejected proposal into approved work. A new proposal may be appropriate when evidence changes, but its relationship to the earlier decision should remain visible.
Recheck the target immediately before execution
Time passes between proposal and execution. The destination record may have changed, the requester may have lost access, or a policy condition may no longer hold. The executor must validate the conditions that remain necessary at the moment it applies the approved action.
Use destination-supported concurrency checks or equivalent guarded operations where appropriate. If the expected record state no longer matches, stop and explain the conflict rather than overwriting newer work. A prior human approval is not a request to ignore changes the reviewer never saw.
Validate arguments as business values as well as data types. A valid record identifier can still refer to a different tenant. An allowed action name can still be unsuitable for the current workflow state. Keep those checks inside trusted services instead of asking the model whether its own request is permissible.
Do not let evidence redefine authority
Retrieved documents and tool results can contain text that resembles instructions. A supplier note might say to ignore review and update a separate record immediately. That material can be evidence relevant to the task, but it must not change tool permissions or create execution authority.
Separate the content the model interprets from the policy the application enforces. Even if a prompt injection persuades the agent to propose an inappropriate action, the executor should still reject missing approval, an invalid target, or a forbidden operation. Defence should not depend on the model always recognizing hostile wording.
Test the read boundary as well. An agent prevented from writing may still request data outside its scope or include sensitive information in a proposal. Restricted data controls and action controls address different effects and should be reviewed together.
Handle uncertain writes without multiplying the mistake
If the destination does not return a clear result, the executor may not know whether an action happened. Preserve that uncertainty. Retrying immediately can repeat a completed operation or produce a different result if the target state changed after the initial attempt.
Use a stable action reference and the destination's supported mechanisms to identify repeated requests or inspect prior outcomes. Reconcile before retrying when the effect is uncertain. The workflow should make the unresolved state visible to an operator rather than presenting the model's optimistic summary as completion.
Recovery may require a compensating action rather than a literal reversal. A sent message, for example, cannot be treated as though nobody received it simply because an internal state is reset. Any corrective outward change should pass through the required proposal and approval path with its own evidence.
Test the executor as an independent boundary
Call the executor in tests with no decision, the wrong reviewer, a modified payload, a different tenant, and a changed target state. It should reject these requests regardless of how confidently the agent describes them. This is deterministic control testing, distinct from asking whether the model usually follows instructions.
Then evaluate the complete workflow with ambiguous names, conflicting evidence, rejected proposals, and instructions embedded in retrieved content. Inspect both attempted actions and confirmed destination effects. A blocked attempt may demonstrate a working final boundary while still exposing a proposal defect worth addressing.
Retain linked records of the proposal, decision, execution checks, and artifact. An audit trail makes it possible to verify that the intended controls operated and to locate the actual failure when they did not. The design should remain understandable to the team that operates it after launch.
Frequently asked questions
Is a system prompt enough to stop an unauthorized action?
No. A system prompt communicates expected behaviour, but an available write tool can still be called incorrectly. Remove direct outward write capability from the agent and enforce permissions, approval binding, and business conditions in trusted application code. Evaluate the model's behaviour while independently testing that the executor refuses work outside its authority.
Can the agent approve its own proposal?
Not in CodeDTX's Propose–Decide–Execute pattern. The agent prepares evidence and a proposed change, while a named human with the relevant authority records the decision. Keep proposal creation separate from decision fields and execution credentials so model output cannot impersonate approval or mutate the workflow into an executable state.
What if a correct action becomes wrong while waiting?
The executor should revalidate the target state, permissions, and other required conditions before applying the change. If the review context is stale, block execution and explain what changed. A revised proposal can then be reviewed against the new evidence instead of forcing an earlier decision onto a situation the reviewer did not assess.
Does a rollback button solve action safety?
A recovery mechanism is useful, but it does not prevent unauthorized actions and may not undo every effect. External recipients may already have seen a message, or another process may have reacted to a record change. Prevent invalid execution first, and design reconciliation and approved corrective actions for failures whose effects cannot simply be erased.
