Glossary

What is an enterprise AI agent?

An enterprise AI agent is an AI agent designed to operate safely on enterprise systems. It reads, writes, and acts on company data the way a member of staff would: under a defined scope, against tested operations, with every action recorded.

What separates an enterprise AI agent from a generic AI agent is not the model behind it. It is the access layer the agent operates through. Five properties show up in every production deployment: governed data access, deterministic execution against tested operations, scoped credentials per agent, durable domain context, and a per-call audit trail separate from the invoking user.

What makes an agent enterprise-ready

Three properties decide whether an agent belongs in production or stays in a demo.

Per-agent scoping

Per-agent, per-table, per-action access. One agent reads Accounts and updates Cases. Another agent has its own scope, defined separately. The agent's reach does not inherit the invoking user's full permissions.

Deterministic execution

The agent calls tested operations with typed parameters. The same question always produces the same answer. No runtime SQL generation that can drift on rephrased questions.

Per-call audit

Every tool call is logged with inputs and result, attributed to the agent itself, not collapsed into the user that invoked it. "The lease agent did it" is a sentence the audit can support.

Why generic AI agents fall over in production

Most current agent tools were written for demos and pushed into production with the same shape. Three failure patterns recur, and each one breaks something real.

The first is CRUD under the invoking user. The agent gets create, read, update, and delete verbs across every table the user can reach. An admin runs the agent, and for the duration of that call the agent has admin rights. There is no way to say "this agent reads accounts but never writes them."

The second is runtime SQL generation. The agent exposes one "query the database" operation and asks the model to write the SQL. The same question can return two different queries on different days, with no guarantee that either is correct. This is the deterministic execution gap.

The third is no per-agent audit dimension. The data system logs whoever invoked the call. If the agent is acting as the user, the audit says the user did it. After the fact, there is no way to ask "what did the lease agent touch this week," because the lease agent does not exist as a distinct actor in the log.

The protocol layer and the governance layer

Model Context Protocol (MCP) is the connectivity standard that lets any agent talk to any tool. It defines how the agent discovers a tool, calls it with parameters, and reads the result back. MCP solves the integration problem.

MCP does not, on its own, decide who can call which tool, what data that tool can reach, or how the call is audited. Those are governance questions. They live in the layer above the protocol, in whatever serves the tool.

An enterprise AI agent is one whose tools are served by a governance layer that enforces per-agent scoping, deterministic execution, durable context, and per-call audit. The protocol is the same as in a demo. The layer above it is what makes the agent fit for production.

How dhino delivers an enterprise AI agent

dhino Trust is the governance layer above MCP. Agents authenticate with their own credentials. Each agent has its own per-table, per-action scope. Tools are named operations carrying tested business logic, not raw CRUD. Every call is logged with inputs and outcome against the agent itself.

For a concrete capability comparison against Microsoft's standard offering, see dhino's Dataverse MCP server vs Microsoft's. For the architectural case, read how AI agents should access enterprise data.

See a governed agent against your own data

Bring one agent you are trying to build or have already shipped. We will walk through the per-agent scope, the tested operations, and the audit trail against your data, not a demo tenant.