The Permission to Build · Article 4 · Your Agent Should Not Have the Nuclear Codes
We finally did it.
We built an AI agent that can read the CRM, query inventory, analyze customer history, create content, send email, update records, publish to social, check pricing, manipulate spreadsheets, trigger automations, call external tools, execute code and presumably order lunch if somebody exposes the right API.
Look at all that innovation.
One small question:
Why does it have permission to do all of those things?
The first wave of enterprise generative AI was largely about intelligence. We asked questions, analyzed information, generated drafts, summarized documents and occasionally used it to shorten a meeting that should have been an email in the first place. The output still generally arrived in front of a human being who decided whether anything happened next.
Agents change that relationship because the model increasingly has access to tools, and tools convert intelligence into consequence. An AI can identify five vehicles that may deserve a pricing review; an agent can change the prices. An AI can determine that a customer needs follow-up; an agent can send the message. An AI can identify a potential compliance problem; an agent can rewrite the content and publish the replacement.
The underlying intelligence may be nearly identical in each example. The authority is not.
That distinction is where agentic AI moves out of the novelty conversation and into executive governance.
A powerful model should not inherit powerful permissions simply because the model is capable of using them.
We have already established that access to enterprise data is a decision. We have established that important applications need to survive their builders. Now we arrive at the next permission: what are we willing to let the machine do?
Automotive is already spending tremendous energy evaluating which models are smartest, which agents are most capable, which coding environments move fastest and which platform can perform the largest number of tasks without human intervention. Those are useful questions, but they can distract from the more consequential architecture underneath them.
Imagine an inventory agent reviewing aged vehicles across a dealer group. It understands days in stock, pricing position, local competition, incentives, merchandising quality, search demand and recent performance. It can explain why a vehicle deserves attention and recommend a next step to the inventory director. That is powerful intelligence.
Now give the same agent authority to change advertised prices. The model did not necessarily become smarter; the organization simply changed the consequences it is allowed to create. If it recommends an adjustment that makes no sense, a human can reject it. If it executes that adjustment automatically across hundreds of vehicles, the same reasoning error becomes an economic event.
The principle applies almost everywhere. A customer-intelligence agent may be exceptionally good at recognizing which leads deserve another conversation, but autonomously deciding which customers no longer deserve one changes the operating model. A content agent may understand the dealership, OEM requirements, local market and Brand Voice beautifully, but publishing authority changes the editorial model. An assistant may identify an unusual pattern in customer records, but permission to modify or delete those records changes the data-governance model.
Capability and authority do not naturally belong together. A dealership controller may understand every number in the financial statement without having unlimited authority to move money anywhere they choose. A service advisor may understand the customer perfectly without possessing administrator access to every system in the dealership. Mature organizations have always separated knowledge, responsibility and authority because the consequences are different.
Agentic AI deserves the same institutional wisdom.
What the model knows matters. What the enterprise allows that knowledge to do may matter more.
The model is also rarely the only thing determining the final outcome. An agent operates inside a larger architecture of tools, identities, APIs, permissions, business rules, connected systems and approval pathways. A highly capable model with narrowly designed tools can operate inside a surprisingly controlled environment. A mediocre model attached to an administrator credential can create a remarkable amount of excitement for entirely different reasons.
The quality bar should rise with the blast radius.
That principle gives leadership a better question than whether the AI is simply “accurate enough.” Accurate enough to do what, for whom, across how many stores, with access to which information, capable of changing what—and what happens on the day it is wrong?
The uncomfortable part is that most organizations will not intentionally hand an AI agent the nuclear codes. The agent will collect them one reasonable permission at a time.
Suppose a dealership marketing team builds an agent to identify vehicles needing merchandising attention. The first version only needs inventory data, so somebody connects a read-only feed. The recommendations are excellent, and the builder realizes the agent could save additional time if it updated a merchandising status after completing its analysis. A write permission gets added. Then it begins creating content for those vehicles, somebody connects the publishing workflow, and another person realizes the agent could compare performance and adjust which vehicles receive additional promotion. The regional team sees the demo and wants the application across the group.
Now one useful experiment can read inventory, create public-facing content, change internal status, invoke publishing workflows and operate across dozens of rooftops. Nothing about that progression is inherently reckless. Every individual request may have been perfectly rational.
Authority usually accumulates through convenience long before anyone sits down to evaluate the total authority the system now possesses.
The same pattern appears in credentials. A developer needs database access and the administrator credential is already available. The agent needs to summarize email, while the integration package happens to expose both read and send capabilities. A pilot requires one store, but the API token carries group-level scope. The application needs one customer attribute while the connected system exposes the entire record. The agent does not need those broader powers to create the intended value; they are simply easier to inherit than to remove.
OWASP has a useful name for the resulting condition: Excessive Agency. OWASP identifies excessive functionality, excessive permissions and excessive autonomy as recurring root causes. That framing shifts the discussion away from whether agents are inherently dangerous and toward whether the agent was designed responsibly for the job it actually has.
An inventory-recommendation agent does not need authority to delete inventory. An email-summary agent does not automatically need permission to send email. A research tool does not automatically need a general-purpose shell. An assistant operating on behalf of one employee does not necessarily need a generic privileged identity capable of accessing everybody’s information.
OWASP’s mitigation guidance follows the same logic: expose only the tools and functions the agent needs, constrain downstream permissions, execute actions inside the appropriate user context where practical, enforce authorization outside the model, and introduce human approval when the consequence justifies it.
Do not give the machine ten doors because opening one of them was convenient. Know which door the agent actually needs.
This becomes particularly important when people start discussing prompt injection, hallucination and other model failures. Those concepts can sound technical enough that executives are tempted to leave them with the security team. The business implication is simpler: models can be wrong.
They can misunderstand an instruction, reason poorly from incomplete information, consume malicious or manipulated content, encounter hostile instructions embedded in a webpage, receive unexpected information from a connected tool or inherit bad context from another agent. OWASP specifically notes that excessive agency can turn hallucinations, direct or indirect prompt injection, compromised tools and malicious peer agents into damaging actions.
The meaningful executive question is therefore not simply whether the model might encounter a bad instruction. It is what can happen after it does.
If an AI produces a strange paragraph in an internal research summary, the problem is annoying. If the same AI can independently email customers, alter CRM records, publish content, execute code and modify pricing, the exact same reasoning failure now has a much larger operating surface. The model failure did not become more sophisticated; the permissions made it more expensive.
This is why the security boundary cannot live primarily inside the prompt. Telling an agent never send a customer message unless you’re sure is an instruction; giving the agent a draft-only email tool is architecture. Telling the agent never delete anything important is an instruction; giving its database identity no DELETE permission is architecture. Telling the model to make only appropriate pricing adjustments may be useful context; constraining the downstream pricing tool to an approved range, approved inventory population and approved user authority is control.
The model should not be the final authority on whether the model is authorized.
That principle survives model changes. The enterprise does not need to assume OpenAI, Anthropic, Google, an open model or today’s preferred provider will always remain the intelligence layer. A different model can reason over the same approved context while downstream systems continue enforcing what that user and agent are actually permitted to do.
That is how intelligence becomes interchangeable without making authority arbitrary.
The answer is not keeping AI permanently read-only. That would be easy to govern and enormously wasteful. The power of agentic AI is precisely that intelligent systems can increasingly eliminate repetitive execution rather than merely describing what a human should execute next. There will be dealership workflows where autonomous execution is faster, more consistent, more accurate and materially better for the customer than waiting for a person to click through another series of screens.
We should use them. The mistake is treating maximum autonomy as the maturity model.
A sophisticated AI project can create significant value long before it operates independently, which gives leadership a safer path for expanding authority as evidence accumulates:
Read → Recommend → Draft → Approve → Act → Automate
An agent may begin by reading approved information and helping the operator understand what deserves attention. As its usefulness becomes clear, it can recommend the next action and eventually prepare that action itself—the customer communication, CRM note, content, pricing recommendation or workflow change. At that point the human is no longer performing the administrative work; they are exercising judgment where judgment still matters.
As the system proves reliable, certain actions may earn permission to execute inside clearly defined boundaries. A content workflow might publish approved classes of content. An inventory workflow might change a defined field. A customer process might perform a routine communication under specific conditions. A pricing system might execute within a narrow approved range. Eventually, some processes may earn broader autonomy because the organization has accumulated enough evidence that the quality, controls and customer outcome justify it.
That progression also gives us a more useful way to think about human in the loop. A human does not need to approve every inventory lookup, retrieval of an approved brand guideline or routine deterministic action simply so the organization can claim somebody was technically involved. Making someone click Approve 4,000 times a day is not oversight; it’s an automation failure wearing a compliance hat.
Human judgment becomes disproportionately valuable where the decision is ambiguous, consequential, novel or unusually sensitive: a difficult customer interaction, material pricing exception, finance claim, compliance edge case, consequential deletion or circumstance where the customer context falls outside the standard workflow.
NIST’s Generative AI Profile similarly treats human oversight as contextual rather than universal, with review and management controls scaling to the nature and risk of the application.
The best human-in-the-loop architecture removes humans from meaningless work while making their judgment more available at meaningful decisions.
Use automation to consume administration around expertise. Do not confuse consuming the administration with eliminating the expertise.
This is where Model Context Protocol becomes especially consequential to the enterprise AI conversation. MCP is helping solve a real interoperability problem by giving intelligent clients a common way to discover and work with external tools, resources and organizational context instead of requiring a bespoke proprietary connection every time another model, coding environment, assistant or application arrives.
The July 28, 2026 MCP specification pushed that infrastructure further toward enterprise operation. Among its changes are a stateless protocol core, header-based method and tool identification that can support routing and authorization at gateways, a formal extensions framework and additional authorization hardening including issuer validation aligned with RFC 9207.
The interesting part for this essay is not the protocol trivia. It is that broader interoperability is developing alongside more deliberate authorization. Those ideas belong together.
Connecting an AI client to a tool does not determine whether the person using that client should be able to call the tool. Exposing a resource does not determine whether every user should see it. Giving an agent access to a business capability does not determine whether the agent should execute that capability autonomously.
MCP is the road. Governance still decides who gets the license, which lanes they can enter, what they are allowed to carry and where they are permitted to go.
That is why the statement “We use MCP, so we’re secure” does not survive serious inspection. MCP is infrastructure on which a strong authorization and governance strategy can operate; it is not a substitute for one.
A mature implementation can answer who the authenticated user is, which resources and tools that user is entitled to access, which scopes apply, whether downstream systems independently enforce the same authority, what gets logged, how permission can be revoked and which consequential actions require additional approval.
This is one of the reasons the interoperability architecture behind Hrizn MCP matters far beyond saying Hrizn can connect to another AI interface. The larger objective is allowing dealership intelligence to remain connected to a governed operating layer while different people and intelligent environments work against the capabilities appropriate to them.
Dealer DNA, Brand Voice, IdeaCloud research, inventory and vehicle intelligence, staff context, market knowledge, content intelligence and compliance can persist while the marketing team, agency or developer chooses different intelligent interfaces. The business does not need to be reconstructed every time the interface changes.
But shared intelligence does not imply shared authority. The person researching a market does not automatically receive the same capabilities as the person publishing dealership content. The application analyzing inventory does not automatically receive the same permissions as the workflow capable of changing pricing. An agency can work against durable dealership context without inheriting every permission available to dealership leadership.
One intelligence layer does not mean one permission level.
That is where interoperability can reduce risk instead of multiplying it. The alternative is every new application building another custom connection, credential set, authentication strategy, dealership knowledge copy and independent interpretation of who is allowed to do what.
Build the road once, govern the lanes and let substantially more people and intelligent systems participate.
A useful demonstration shows leadership what an agent can do. A mature production conversation should also demonstrate how quickly the enterprise can make it stop, which becomes more complicated as agentic workflows span multiple systems.
Suppose an agent identifies qualifying customers, generates a message, pushes that message into another communication platform and schedules delivery through a downstream automation. Stopping the original model session may not stop the campaign. Work may already be queued, the downstream platform may possess its own credentials and the original agent may no longer be involved by the time the customer receives the message.
The organization therefore needs to understand the entire consequence chain, not merely the intelligence that initiated it.
These controls become more important as autonomy increases because autonomy compresses the time between a bad decision and its consequences. OWASP recommends logging and monitoring tool activity and downstream actions and points to rate limiting as one way to constrain undesirable behavior before it spreads. The FTC’s dealer guidance arrives at similar operating discipline from the standpoint of protected customer information through requirements around access controls, authentication, monitoring, testing and service-provider oversight.
Different frameworks arrive at the same practical conclusion: important systems should leave evidence, and consequential systems should leave the enterprise a way back in.
This is why the kill switch should not be a metaphor. It is the capability to revoke a token, disable a workflow, remove a tool, suspend an integration, pause a store, limit a transaction, escalate an exception, review a log and restore a previous state where practical.
Those controls do not make the agent less sophisticated. They create the confidence necessary to let a sophisticated agent do more.
The ability to stop an autonomous system is part of the architecture that earns it permission to become autonomous.
There is one part of this conversation that OWASP, NIST, the FTC and the MCP specification cannot decide for the dealership: which parts of the customer experience should actually become autonomous?
Automotive is about to be offered an agent for nearly everything—BDC, sales follow-up, service outreach, marketing, inventory, reporting, content, pricing, customer support and management. Eventually we will need an agent whose primary responsibility is explaining what all the other agents are doing.
Some of these applications are going to be extraordinary. Use them.
There are enormous amounts of administrative work inside automotive that deserve to disappear. Employees spend too much time moving information between systems, rebuilding reports, repeating known processes, searching for context, copying data and performing tasks software should have consumed a decade ago. AI gives us the opportunity to finally eliminate a meaningful amount of that work.
But the existence of an automatable process does not prove the process deserves to continue unchanged with the human removed. Sometimes the process itself should disappear. Sometimes the handoff needs redesigning. Sometimes AI should prepare the employee so completely that the employee can finally concentrate on the part customers value. Sometimes full autonomy is unquestionably the better experience.
Leadership has to decide which is which because giving an agent authority is not merely a cybersecurity decision. Automatically sending 10,000 follow-up messages is a customer-experience decision. Determining which leads no longer deserve attention is a sales-process decision. Changing an advertised price is an economic decision. Publishing content without review is an editorial decision. Altering customer records is a data-governance decision.
The absence of a human click does not remove human responsibility from any of them.
Autonomy does not eliminate accountability. It moves accountability upstream to the people who decided what the system was allowed to do.
The objective should therefore not be creating the most autonomous dealership, agency, dealer group or OEM. It should be creating the most capable organization operating inside consequences it understands and intentionally accepts.
Let intelligent systems research, reason, create, eliminate administrative work, recommend and prepare actions. When evidence demonstrates that the customer, employee and enterprise are better served by allowing bounded execution, give the system more authority. When those workflows demonstrate sufficient reliability, control and customer value, let greater autonomy become something the system earns.
That is a much more ambitious vision for agentic AI than simply removing humans from workflows. It creates an environment where machines can become more capable because leadership has enough governance, interoperability, observability and control to trust them with increasingly important work.
The larger opportunity behind Hrizn v6 is an enterprise that does not have to reinvent dealership identity, context, permissions, compliance and organizational memory every time the model, development environment, employee, agency or application changes.
Give builders the road, give agents the lane they actually need and preserve human judgment where judgment creates disproportionate value. Then move fast.
The goal is building AI infrastructure mature enough that the enterprise can responsibly let it do extraordinary things.
We now have almost everything. The project has a legitimate purpose, the data access is intentional, the business can survive the builder and the agent’s authority reflects the consequence.
One final question remains: does any of that prove the project deserves to become enterprise infrastructure?
The demo proves possibility. Now we need receipts.
Previous: The Bus-Factor App: What Happens When Your Vibe Coder Quits? →
Return to the series hub: The Permission to Build: AI Made Software Cheap. Leadership Still Owns the Consequences.
OWASP: Excessive Agency →
Guidance on unnecessary agent functionality, permissions and autonomy, with practical mitigations including least privilege, downstream authorization and human approval.
NIST AI Risk Management Framework →
A lifecycle framework for managing trustworthy and responsible AI.
NIST Generative AI Profile →
Generative-AI guidance covering governance, testing, human oversight, documentation and risk.
Model Context Protocol: 2026-07-28 Specification →
The current MCP release, including the stateless protocol core, authorization hardening, header-based routing and extensions framework.
FTC: Automobile Dealers and the Safeguards Rule →
Dealer-specific guidance on customer-information security, access controls, authentication, monitoring and service-provider oversight.
Hrizn MCP →
Explore how authorized builders and AI environments can work from common dealership intelligence while preserving different scopes of access and action.
Interoperability should make extraordinary AI capability easier to use without quietly turning every connected system into an administrator.
Hrizn v6 and Hrizn MCP keep dealership intelligence, research, inventory, staff context, Brand Voice, market knowledge, content and compliance connected to a durable operating layer while authorized users and applications work within the capabilities appropriate to their role.
Connect the intelligence. Scope the authority. Let autonomy earn the right to scale.
Hrizn v6 helps dealership marketing teams move from fragmented activity toward a connected operating advantage—bringing intelligence, creation, human participation, distribution, proof and improvement into a more coherent system.
The agentic opportunity is creating an interoperable operating environment where intelligent systems can take increasingly useful action without separating authority, customer context and accountability from the enterprise that ultimately owns the outcome.
We Rise Together.
