# Enterprise agentic AI platform: what IT should demand

> An agent that reads your documents and acts inside your tools is no longer a productivity gadget: it is a new user of your information system. This guide does not redefine agentic AI. It lists what IT should demand from a platform before letting it act, and how to check it.

Source: https://smartagt.ai/en/ressources/plateforme-agentique/
Published: 2026-09-22
Publisher: SmartAGT (NERVIAL LABS)

---
## What an agentic platform changes for IT {#stakes}

A chat assistant answers a question. An agent is given a goal, picks tools, calls them, reads the result and repeats until it reaches what it was asked for. It can search a document base, read a mailbox, open a ticket, update a customer record. The difference is covered in the guide [agent, assistant or chatbot](~/ressources/agent-assistant-chatbot/); what matters here is the consequence.

As soon as software decides for itself which tool to call, security can no longer rely only on the path a developer planned. The language model can misread an instruction, be misled by content it reads (a booby-trapped email, a web page), or chain calls nobody anticipated. An enterprise agentic platform is therefore less a tool for building agents than an **execution framework**: what decides what an agent may see and do, what must be confirmed by a person, and what stays on record.

- **The model** It interprets the request and proposes the next action. It is sometimes wrong, without warning.
- **The tools** Connectors to email, documents, ERP, CRM. They are what produce real effects.
- **The framework** Identity, permissions, human approval, audit trail, limits. This is what IT is really buying.

*An agent is a model that picks tools. The platform is the framework that bounds those choices.*

Demos show the first two blocks. Incidents almost always start in the third. The five requirements below are about it.

## Requirement 1: permissions that follow the user {#permissions}

The most important question fits on one line: **whose permissions does the agent act with?**

The easy, and dangerous, answer is a service account. The agent connects to the CRM or the document store with a technical account that sees everything, and the platform takes care of “only showing what it should”. In practice, filtering then relies on the model or on an application layer added afterwards. An employee can get, through the agent, a document they cannot open directly. That is privilege escalation, not a feature.

The right answer: the agent acts **on behalf of the user running it, with their permissions and nothing more**. If the person cannot open a file in the source tool, the agent cannot open it for them. This requires a link to your directory and connectors that authenticate on behalf of the user, rather than with a shared key.

Three points to check:

- **Indexed documents** respect the permissions of their source. An internal search engine that ignores access rights turns the document base into a company-wide leak.
- **Shared agents**: an agent built by one team and used by others must not pass its creator's permissions on to its users.
- **Revocation**: a departure, a change of role or a removed connection must cut the agent's access immediately, without waiting for a resync.

Authentication modes and the risks specific to each type of tool are covered in the guide [connecting an AI agent to your systems](~/ressources/connecter-agent-si/).

## Requirement 2: human control over actions that commit {#human-control}

An agent that reads and summarises has no effect on the real world. An agent that sends an email, changes an order or deletes a file does. For these actions, the platform must **suspend execution and ask for human confirmation**, and that suspension must be deterministic: it depends on the nature of the action, not on the model's judgement.

This is where offers differ most clearly. Many solutions ask the model to “be careful” or to “ask for confirmation when needed”. That is an instruction, not a control: the same model that can get the action wrong also decides whether to show it to you.

What to demand:

- a **classification of actions** by nature (read, write, execute), attached to each tool, not guessed at run time;
- a **confirmation that shows exactly** what will be executed: recipient, content, fields changed, not a summary written by the model;
- a **logged decision** with the identity of the person who confirmed or rejected.

The guide [human approval of an AI agent](~/ressources/validation-humaine-agent/) details which actions to submit for approval and how to design an approval step that is still read at the hundredth request.

> **Watch out** An approval shown for every action, reads included, ends up being clicked through without being read. Useful human control is rare and precise, not systematic.

## Requirement 3: governed connectors, not raw access {#connectors}

An agent's value depends on the tools it can reach. So does its risk surface. An enterprise platform must therefore treat connectors as an **administered catalogue**, not as a list of API keys each user plugs in as they please.

In practice:

- **The administrator decides** which connectors are available, to which groups, and which operations of each connector are exposed. A support agent does not need to be able to delete a contact in the CRM.
- **Operations are described**: for each tool, what it reads, what it writes, what it executes. That description is what drives the human approval of the previous requirement.
- **Open protocols are governed**. The [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro) (MCP) lets an agent plug into many tools through an open standard. It is a real integration gain, but a third-party MCP server is code that exposes actions: it must go through the same catalogue, the same permissions and the same approval as native connectors.

The [OWASP list of LLM application risks](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) calls this risk “excessive agency” and gives three causes: too much functionality, too many permissions, too much autonomy. The first three requirements of this guide answer them one by one.

## Requirement 4: a usable audit trail, not a debug log {#audit-trail}

When an agent has sent a message it should not have sent, three people ask different questions. The business wants to know what happened. The CISO wants to know whether it was an attack. The DPO wants to know which data moved. The platform must let you answer all three.

A usable trail records, for each run:

- **who** started the agent, and **on whose behalf** it acted;
- **which model** was called, with which document sources;
- **which tools** were called, with which parameters and which result;
- **which human decisions** were made, by whom and when.

Two properties separate an audit trail from a plain log. First, **integrity**: you must be able to show that no entry was changed or deleted afterwards, for instance through verifiable cryptographic chaining. Second, **minimisation**: logging an action does not mean keeping the full content of every conversation forever, which may contain personal data. The trail must be useful without becoming a store of sensitive data itself.

## Requirement 5: control over models and costs {#models-costs}

An agent consumes far more than a chat assistant: every reasoning step, every document read, every tool call goes back through the model. An agent looping on a poorly defined task can multiply consumption without anyone noticing before the invoice.

What to demand:

- **Model choice per use case**. Sorting emails does not need the same model as analysing a contract. The platform must let you connect several providers, including models running on your own infrastructure, and switch without rewriting the agents.
- **Limits that block**, per user, per group or per agent, not just alerts after the fact.
- **A readable cost**, per agent and per model, in a unit your finance team understands. Vendor-specific credits make any comparison impossible.
- **Control over where processing happens**. The data an agent reads goes to the model it calls. Choosing between a local model, a European provider or a non-European provider is therefore also a compliance choice. The guide [on-premise generative AI](~/ressources/ia-on-premise/) covers that trade-off.

## The buying checklist, requirement by requirement {#checklist}

Sales answers all sound alike. The questions below force answers you can check, and the third column lists the answers that should worry you.

| Requirement | The question to ask | Weak answer |
| --- | --- | --- |
| Permissions | Can a user get, through the agent, a document they cannot open directly? | “The model is configured not to do that.” |
| Human control | What triggers the confirmation request, and who decides? | “The agent asks for confirmation when it sees fit.” |
| Connectors | Can I disable one specific operation of a connector for a given group? | “The connector is either on or off.” |
| Audit trail | How do you prove a log entry has not been altered? | “Logs are kept on our servers.” |
| Models | Can I switch an agent to another model without rebuilding it? | “Our agents are optimised for our model.” |
| Costs | What happens when a group reaches its limit? | “You get a notification.” |
| Data | If I cut all outbound traffic, what stops working? | A vague answer, or none. |

The checklist is verified in practice, not on slides. A useful proof of concept runs in your environment, with your accounts and your test data:

- **Two users with different permissions** Ask the agent the same question as each of them. The answers must reflect their respective permissions.
- **A write action** Ask the agent to send a message or update a record. Execution must stop and show the exact action.
- **A booby-trapped document** Have the agent read a document containing a hidden instruction. It must not be able to act without going through approval.
- **A limit reached** Set a low limit on a test group and check that consumption stops.
- **Reading back the trail** Find every step of the test in the log, with actors and decisions.

*Five tests that separate platforms in a day, in your own environment.*

## Frequently asked questions {#faq}

### Do we need a dedicated platform, or are the agents built into existing software enough?

Agents built into a business application work well inside that application. As soon as a use case spans several tools, for instance reading an email, checking the CRM and opening a ticket, you need a common framework for permissions, approval and audit. Otherwise each vendor applies its own rules and nobody has the full picture.

### Is an agentic platform covered by the AI Act?

It depends on the use cases more than on the tool. The regulation classifies systems by purpose: an agent that screens job applications does not fall under the same regime as an agent that summarises meeting notes. Above all, a platform must give you the means to meet your obligations on risky use cases: human oversight, logging, transparency.

### Can business teams build their own agents?

Yes, if the framework is held by the platform and not by each agent builder. Permissions, the connector catalogue, action approval and limits then apply whatever the agent, including those built without IT's help.

### Where SmartAGT fits
SmartAGT is a platform for governed AI agents, deployed on-premise inside your perimeter. Each connector acts with the permissions of the connected account, and any write or execute action is paused deterministically until a person confirms or rejects it, with the decision logged.
Runs go into a hash-chained audit trail that can be verified end to end. The model is your choice, from fully local to cloud providers you contract directly, with quotas per user or per group and costs tracked in real money. The list of connectors and providers is on the [Integrations](~/integrations/) page.