{"slug": "ai-should-propose-systems-should-verify", "title": "AI Should Propose. Systems Should Verify.", "summary": "A developer argues that AI agents should be treated as proposing actions rather than executing them directly, with a separate control layer handling validation, authorization, and execution. The proposed architecture routes agent output through system validation and policy checks before infrastructure acts, distinguishing correctness from authority and reasoning from execution. It also recommends scoping controls by actor, action, resource, environment, scope, context, and policy rather than coarse tool-level access.", "body_md": "An AI agent can produce the correct action and still have no authority to execute it.\n\nThat distinction becomes critical when agents move beyond generating text and start modifying code, calling APIs, changing infrastructure, triggering workflows, or coordinating other agents.\n\nThe question is no longer only:\n\nCan the model determine what should happen?\n\nIt is also:\n\nWhat happens between the action the model proposes and the action the system actually executes?\n\nA useful starting point is:\n\n**AI proposes. Systems verify. Infrastructure executes.**\n\nConsider an AI coding agent working inside a production environment.\n\nThe agent receives a task:\n\nFix the authentication bug and deploy the change.\n\nIt analyzes the repository, modifies the code, runs tests, and produces a deployment command.\n\nThe code may be correct.\n\nThe tests may pass.\n\nThe deployment command may be valid.\n\nNone of those facts automatically mean the agent should be allowed to deploy to production.\n\nThis is the difference between **correctness and authority**.\n\nA model can correctly determine what should happen while still being unauthorized to perform that action.\n\nIf the same component controls reasoning, authorization, and execution, the trust boundary becomes extremely large:\n\n```\nAI decides what to do → AI decides whether it may do it → AI executes it\n```\n\nA safer architecture separates those responsibilities.\n\nInstead of allowing the model to directly invoke sensitive infrastructure, treat its output as a **proposed action**.\n\n```\nUser Intent\n    ↓\nAI Agent\n    ↓\nProposed Action\n    ↓\nSystem Validation\n    ↓\nPolicy Check\n    ↓\nExecution\n    ↓\nPost-Execution Verification\n```\n\nThe model produces the request.\n\nThe surrounding system evaluates it.\n\nThe infrastructure executes it only after the required controls have been satisfied.\n\nFor example:\n\n```\n{\n  \"action\": \"deploy\",\n  \"environment\": \"production\",\n  \"service\": \"auth-service\",\n  \"version\": \"2026.10.04\"\n}\n```\n\nThe control layer can independently check whether the request is structurally valid, whether the target exists, whether the requested operation is permitted, and whether additional controls are required.\n\nThe model does not need to make those decisions itself.\n\nImagine the coding agent changes a payment service.\n\nThe tests pass.\n\nThe security checks pass.\n\nThe build succeeds.\n\nThe artifact is signed.\n\nThe model now proposes:\n\nDeploy to production.\n\nThe previous results establish that the software may be technically acceptable.\n\nThey do not establish that the current actor is authorized to deploy it.\n\nThat gives us an important separation:\n\n```\nValidation → Is this action acceptable as an operation?\n\nAuthorization → Is this actor allowed to perform it?\n\nExecution → Perform the approved operation.\n```\n\nThese questions belong to different layers.\n\nThat separation also makes the architecture easier to audit and change without changing the model's reasoning process.\n\nSeparating reasoning from execution does not require making the agent weak.\n\nAn engineering agent can still have broad capabilities:\n\nThe system can simply apply stronger controls to higher-impact operations such as:\n\nThe agent remains capable of reasoning about complex operations.\n\nIts capabilities just do not automatically become unrestricted authority.\n\nAnother architectural mistake is defining control only around tool access.\n\n```\nAgent → deploy_tool\nAgent → payment_api\nAgent → database_api\n```\n\nTool access is often too coarse.\n\nThe more useful question is:\n\nWhat action is the agent attempting to perform, against which resource, under which constraints?\n\nA control layer can therefore reason about something closer to:\n\n```\nActor → Action → Resource → Environment → Scope → Context → Policy\n```\n\nNow the system can distinguish between actions that happen to use the same underlying tool.\n\nA deployment API, for example, might be capable of deploying to both staging and production. Access to the API alone does not tell us whether a particular production deployment should be allowed.\n\nThe meaningful unit of control is the **action and its context**, not simply the existence of a tool.\n\nThe boundary becomes even more important when one agent delegates work to another.\n\nConsider:\n\n```\nUser → Orchestrator Agent → Procurement Agent → Payment Service\n```\n\nThe procurement agent may determine that a purchase is necessary.\n\nBut the fact that the orchestrator requested the purchase does not automatically give the procurement agent unlimited spending authority.\n\nNow the system needs to understand more than the requested action:\n\n```\nInitiator → Delegator → Acting Agent → Action → Resource → Scope\n```\n\nThis introduces a deeper authorization problem: **how authority is delegated between actors**.\n\nThat problem deserves its own layer rather than being squeezed into the basic execution model.\n\nInstead of:\n\n```\nUser → AI → Everything\n```\n\nthink about:\n\n```\nUser → Intent → AI Agent → Proposed Action → System Controls → Infrastructure\n```\n\nThe AI sits inside the system.\n\nIt does not become the system.\n\nThat gives the architecture a stable control boundary around a component whose behavior is probabilistic.\n\nThe model can change.\n\nThe model can be upgraded.\n\nThe model can be replaced.\n\nThe surrounding execution controls can remain.\n\nGiving an AI agent more tools does not automatically mean giving it more authority.\n\nThe goal is not to prevent AI from acting.\n\nThe goal is to separate **the ability to propose an action** from **the authority to execute it**.\n\nAnd once agents start acting on behalf of other agents, the next question becomes unavoidable:\n\n**Who actually has the authority to perform the action?**", "url": "https://wpnews.pro/news/ai-should-propose-systems-should-verify", "canonical_source": "https://dev.to/sinarezaei/ai-should-propose-systems-should-verify-13f7", "published_at": "2026-10-07 05:44:22+00:00", "updated_at": "2026-10-07 05:47:38.256952+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "mlops"], "entities": [], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/ai-should-propose-systems-should-verify", "markdown": "https://wpnews.pro/news/ai-should-propose-systems-should-verify.md", "text": "https://wpnews.pro/news/ai-should-propose-systems-should-verify.txt", "jsonld": "https://wpnews.pro/news/ai-should-propose-systems-should-verify.jsonld"}}