Most enterprise AI agent failures do not start with the model choosing a tool.

They start with a weak contract around what that tool means. A function schema says send_email(to, subject, body). It does not say who is allowed to send, whether the recipient is external, what approval state is required, whether the operation is idempotent, how retries behave, what evidence must be logged, what happens on partial failure, or how the action is reversed.

That missing contract is where a helpful assistant becomes an uncontrolled production actor.

A robot operator copilot should make the human faster at understanding the machine. It should not quietly become the machine’s commander.

That distinction sounds simple until the copilot can read diagnostics, inspect maps, summarize camera events, propose recovery actions, call ROS 2 tools, open maintenance tickets, and ask the robot to dock, pause, resume, retry, or change mode. At that point the design question is no longer “can the model help the operator?” It is:

Which layer is allowed to advise, which layer is allowed to approve, and which layer is allowed to command the robot?

Enterprise AI permissions do not fail only at launch. They drift after launch.

The support agent gets a temporary CRM write scope for a pilot. The HR assistant inherits a broader document collection during migration. A service account remains active after a workflow is retired. A connector adds a new destructive action under an existing integration. Nobody sees the problem because the original security review was treated as a project milestone, not as a recurring control.

An access review for enterprise AI agents is the recurring process that proves each agent still needs each data source, tool action, delegated scope, memory store, model route, and approval bypass it can use. The review should not ask, “does this app still exist?” It should ask, “is this exact authority still justified by current business use, current evidence, current risk, and a named owner?”

An AI-enabled robot should not ask “what can I do next?” until the system has answered a quieter question:

Can the robot trust the state it is about to act on?

That question belongs between perception and authority. It is not enough for the camera node to publish, the LiDAR to spin, the estimator to output a pose, and the planner to return a path. A robot can have all of those things and still be acting on stale localization, overconfident covariance, a half-dead obstacle layer, a drifting transform, or a perception model that is uncertain in exactly the part of the scene that matters.

Most enterprises do not lose control of AI because they lack a policy.

They lose control because nobody can answer the operational inventory questions fast enough: which AI systems exist, who owns them, which data they can see, which tools they can call, which model routes they use, which eval gate approved them, what changed last week, and how to shut one down without breaking a business process.

An enterprise AI system registry is the inventory that makes those questions answerable. It is not a spreadsheet for annual compliance. It is the control-routing table for production AI.

Robot autonomy should not move from simulation to the real world because the demo looked good.

It should move because the system has earned a specific level of physical authority.

That distinction changes how a robotics team ships. The release question is not “does the model work?” or “did the robot complete the task in the lab?” The release question is more concrete: what evidence proves that this robot may accept this class of goals, inside this operating envelope, with these fallbacks, under this supervision model?

Most enterprise AI pilots do not fail because nobody ran an eval. They fail because the eval had no authority.

A team runs a few golden prompts, checks that the assistant sounds reasonable, screenshots the result into a launch document, and moves on. Two weeks later the retrieval index changes, a model route is updated, a tool schema adds a field, a policy prompt is edited, or an upstream document owner reorganizes a knowledge base. The workflow is now different, but the evidence still describes the old system.

An eval gate is the opposite pattern: a release control that decides whether an AI workflow may move from draft to pilot, pilot to production, production to expanded authority, or production back to containment.

Shadow AI is not mainly a policy failure. It is an architecture feedback signal.

When employees paste sensitive context into unmanaged AI tools, install browser extensions, connect unreviewed copilots to SaaS systems, or build small agents with personal API keys, the organization has learned something important: the official path is slower, less useful, or less available than the work people are trying to do.

The governance response should not be blanket prohibition. It should be a control architecture that discovers real usage, separates low-risk experimentation from dangerous execution, gives teams approved paths, and preserves enough evidence for security, compliance, and business ownership to act.

A Jetson container that starts cleanly is not necessarily production-ready.

It may see the GPU but not the right camera. It may publish ROS 2 topics but publish them too late. It may restart after a crash but lose the evidence needed to debug the crash. It may run a perception model at 30 FPS on the bench and then fail under thermal throttling, disk pressure, USB reconnection, DDS discovery delay, or a model update that changed memory behavior.

The practical question is:

What must be true before an edge AI container on a Jetson is allowed to influence a robot?

Zero Trust for AI agents is not “put the chatbot behind SSO.”

That is the login layer. It proves that a user reached the application. It does not prove that the agent should retrieve a specific source, call a specific tool, write a specific field, reuse a memory, send an external message, or act through a particular service account.

The hard enterprise question is narrower and more important:

How should an AI agent receive just enough delegated authority to complete one task, through one governed tool path, with evidence that can be audited later?