How should companies separate proposal, approval, and execution authority?
Operationally separate the right to suggest, authorize, and commit a mutation so accountability and risk controls remain clear.
Short answer
Operationally separate the right to suggest, authorize, and commit a mutation so accountability and risk controls remain clear.
Core explanation
As AI agents and automations gain more access to production systems, companies may need to separate three different responsibilities:
Proposal authority Who or what is allowed to suggest a change?
This could include employees, agencies, AI agents, automated systems, or external applications.
Approval authority Who or what is allowed to determine that a specific proposed change may proceed?
Approval may depend on:
- the affected field
- the size of the change
- business risk
- policy compliance
- whether the change is unusual or exceptional
- whether customer, financial, or regulatory impact is possible
Execution authority Who or what is allowed to commit the approved change to production?
Keeping these responsibilities separate can reduce the risk of one actor controlling the entire decision chain.
A possible model is:
proposal → policy evaluation → approval if required → authorized execution → verification
That does not necessarily mean three different people need to be involved.
The separation can be logical.
For example:
- an AI agent proposes a product update
- policy automatically approves low-risk changes
- a human reviews exceptions or higher-risk changes
- a separate execution service performs the production write
- the resulting state is verified afterward
The important point is that being allowed to propose a change should not automatically mean being allowed to approve and execute it.
Similarly, approval should authorize a specific mutation, not provide unlimited production authority to the actor that requested it.
This becomes especially important when dealing with:
- AI agents
- bulk operations
- sensitive fields
- multiple stores
- multiple contributors
- conflicting automations
- actions with downstream effects
A useful principle might be:
Separate authority according to risk, not according to organizational complexity.
Low-risk changes can remain highly automated.
Higher-risk changes can introduce independent approval without requiring every workflow to become manual.
CommerceGov position
CommerceGov’s position is that authority separation should be implemented as an explicit workflow boundary, so policy and accountability remain visible between proposal and production execution.
Key concepts
- proposal authority
- approval authority
- execution authority
- risk-based policy
- verified production outcome
Related resources
- QuestionWho should have authority to propose, approve, and execute an ecommerce changeProposal, approval, and execution are distinct authorities and may be logically separated even when low-risk policy permits an automated path.
- QuestionShould the same AI agent be allowed to propose and execute a production changeThe same agent may propose and execute a bounded, policy-compliant, reversible change when the execution path is independently constrained; high-impact, uncertain, or exceptional changes need stronger independent controls.
- QuestionWhich ecommerce changes should require human approvalHuman approval should be required when a change exceeds the automated risk boundary defined by policy; assess field sensitivity, scope, customer impact, reversibility, and exceptions rather than requiring review for every action.
- QuestionHow should approval requirements change based on riskApproval tiers should scale from automatic progression for policy-compliant low-risk changes to review, escalation, or explicit authorization as the mutation’s risk increases.
- GuideShould AI agents be allowed to make changes directly in productionAI agents may make changes directly in production when a specific action falls within explicit, risk-appropriate policy and bounded execution authority. Direct execution should not be universal, and it does not require a human to approve every low-risk mutation; higher-impact, exceptional, or uncertain changes need stronger authorization or escalation.
- ConceptWhat is the difference between access control and change governanceAccess control determines who or what can perform a class of action. Change governance decides whether a specific proposal is allowed under current policy, state, risk, and authority.
- QuestionCan low-risk AI changes be automatically approved by policyYes. Low-risk, policy-compliant changes may progress automatically when they remain within explicit field, scope, state, and impact limits; exceptions and elevated-risk changes are reviewed or escalated.