{"slug": "naeos-technical-build-log-002-intent-is-not-authority", "title": "NAEOS Technical Build Log #002 Intent Is Not Authority", "summary": "A developer is building NAEOS, an open-source engineering layer for AI coding agents that separates agent intent from authorization, so a model can propose an action without being the authority that approves it. The design routes actions through a pipeline of Agent → Proposal → Policy → Authorization → Runtime → Observation, producing auditable records such as \"Policy P-014 authorized capability C-003 under version V-2\" followed by an execution receipt. The project argues that prompt instructions and in-context policy files influence a model but do not constitute an independent authorization boundary.", "body_md": "One assumption keeps appearing in AI agent systems:\n\nIf the model understands what needs to be done, it can decide what should be done.\n\nI don't think those are the same problem.\n\nAn AI coding agent can produce an excellent plan.\n\nIt can understand the repository.\n\nIt can identify the required files.\n\nIt can even correctly predict the command that needs to be executed.\n\nBut none of that means the agent is authorized to execute the action.\n\nThis distinction is becoming one of the core ideas behind NAEOS:\n\n**Intent ≠ Authorization**\n\nThe model produces intent.\n\nA policy system determines whether that intent is allowed.\n\nThe runtime executes an authorized action.\n\nAnd observation verifies what actually happened.\n\nSo the flow becomes:\n\n**Agent → Proposal → Policy → Authorization → Runtime → Observation**\n\nThis sounds like additional complexity.\n\nBut consider what happens without the separation.\n\nAn agent receives:\n\n“Update the production configuration.”\n\nThe model decides:\n\n“I need to modify this configuration file and restart the service.”\n\nWhat prevents the model from deciding that the restart is also allowed?\n\nPrompt instructions?\n\nSystem messages?\n\nA policy file inside the context?\n\nThose mechanisms can influence the model.\n\nThey don't necessarily constitute an independent authorization boundary.\n\nThat's the problem I'm trying to address with NAEOS.\n\nThe model should be able to propose an action without becoming the authority that approves the action.\n\nThis also creates a cleaner audit model.\n\nInstead of:\n\nAgent said it was allowed.\n\nwe want:\n\nPolicy P-014 authorized capability C-003 under version V-2.\n\nThen:\n\nRuntime executed C-003.\n\nExternal observation produced receipt R-8291.\n\nNow the system can distinguish what was proposed, what was authorized, what was executed, and what was actually observed.\n\nThat's a very different trust model.\n\nI'm currently implementing and testing these ideas in NAEOS as an open-source engineering layer around AI coding agents.\n\nThe interesting question for me isn't:\n\n**“How do we make agents more obedient?”**\n\nIt's:\n\n**“How do we design the system so obedience isn't the security boundary?”**\n\nRepository:\n\n[https://github.com/NAEOS-foundation/naeos](https://github.com/NAEOS-foundation/naeos)\n\nHow are you currently separating **agent intent** from **actual authorization** in your AI systems?", "url": "https://wpnews.pro/news/naeos-technical-build-log-002-intent-is-not-authority", "canonical_source": "https://dev.to/bayu911/naeos-technical-build-log-002-intent-is-not-authority-581b", "published_at": "2026-09-24 16:03:08+00:00", "updated_at": "2026-09-24 16:30:11.526420+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-tools", "developer-tools"], "entities": ["NAEOS", "NAEOS-foundation", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/naeos-technical-build-log-002-intent-is-not-authority", "markdown": "https://wpnews.pro/news/naeos-technical-build-log-002-intent-is-not-authority.md", "text": "https://wpnews.pro/news/naeos-technical-build-log-002-intent-is-not-authority.txt", "jsonld": "https://wpnews.pro/news/naeos-technical-build-log-002-intent-is-not-authority.jsonld"}}