Action control guides · MCP gateway versus action control
A gateway connects the tool. Action control decides whether this change runs.
A failing control often needs one change in a production system: remove a GitHub organization owner, deactivate an AWS access key. An MCP gateway gives the agent a path to that tool. Deixic checks the target and the policy when the agent requests the change, and the policy decides whether it runs.
The gateway boundary
A gateway registers tools, carries authentication, and routes calls to a connected system. Those controls establish that the agent can reach GitHub or AWS.
- Object
- Tool connection
- Decision time
- Registration and request routing
- Result
- A callable tool path
The action-control boundary
Deixic evaluates each requested change before execution. Deactivating an access key falls inside the policy you grant. Removing production admin waits for a named approver. Deleting an account is outside the policy and is refused.
- Object
- One requested change
- Decision time
- Immediately before execution
- Result
- Allowed, refused, or awaiting approval
After the call
Deixic reads the setting back from the system after the change, compares it with the desired state, and keeps the before and after state in the receipt.
- Evidence
- Read-back check and receipt
Use both boundaries
Keep tool registration and credentials at the gateway. Put every production change, including the fixes for failing controls, under action policy.
Reuse the fix the next time the control fails.
Activity history records each fix and the authority behind it. Save a repeated fix as a skill and replay real sessions when the method changes.
See compliance executionSee the execution path