Announcing US$ 3.2M pre-seed round · OneVC · Maya · Norte Ventures Read →
Back to blog

Access control in AI agents:
who sees what in each answer

In short

An AI agent that supports the legal team queries the drive, contract management and email. Among the documents it can reach are contracts under a confidentiality clause, open only to the lawyers on each case. If the agent answers anyone in the department with everything it can read, the clause loses its effect. Access control is the set of rules that defines who can see or change each piece of data. With agents, it has to follow every query, and it is one of the functions of the Company Brain, the layer that knows the company: what data exists, where it lives, how it relates and who can see what.

Access control defines who can see or change each piece of data

Every enterprise system answers three questions before displaying a record: who is asking, what that identity can do and on which records. Authentication settles the first. Access control settles the other two, with rules for reading, changing and deleting. Three models are the most widely used:

  • RBAC, by role: permissions are assigned to functions, such as HR manager, and each person receives the permissions of the roles they hold.
  • ABAC, by attribute: the rule evaluates characteristics of the person, the data and the situation, such as department, business unit or the document's classification.
  • By record or row: the rule filters which items in a table each person sees, such as the reviews of their own team.

Access control in an HRIS usually combines all three. The manager role unlocks the performance module, the business unit attribute restricts it to the branch and the row-level rule shows only direct reports.

Three access control models: role-based (RBAC), attribute-based (ABAC) and record-level
Role-based, attribute-based and record-level access control models usually work together

AI agents change the path data takes to the answer

In traditional systems, the person opens the screen and the system applies the rule. With an agent, an intermediary appears that receives the question, queries several systems and assembles a single answer. It acts on someone's behalf, and every system it queries needs to know on whose behalf.

The answer also mixes sources with different rules. A question about an employee may bring together the HRIS, payroll and internal tickets. If one source releases more than it should, the excess goes into the answer along with everything else.

The language model does not enforce permissions on its own. An instruction in the prompt to leave out restricted data depends on the most likely continuation and can be circumvented by a well-phrased question. Access control has to happen earlier, when the sources are queried.

Five patterns concentrate the access control risk with agents

  • Service account with broad access: the agent reads the HRIS with a technical credential, and whoever asks receives performance reviews for the whole company.
  • Single index with no filter: a hospital's medical records and clinical protocols go into the same search base, without restricting each record to the team caring for the patient.
  • Copied permissions: the project replicates the source's rules once, and the lawyer who left a case keeps receiving its documents.
  • Delegation with no scope limit: the authorisation given to the agent applies to every system and operation, including those the task does not need.
  • Agent that writes to systems: a misinterpretation becomes a changed record or a document sent out.

The 2025 edition of the OWASP list for LLM applications covers several of these risks under excessive agency and recommends executing actions taken on a user's behalf in that user's context, with the minimum privilege necessary.

Five access control risk patterns in projects with AI agents
Five designs account for most access control incidents with AI agents

Access control principles apply to every call the agent makes

  1. Least privilege: each agent and each tool receives only the access the task requires.
  2. Propagated identity: the query reaches the source with the identity of whoever asked.
  3. Filter before the model: restricted data drops out at query time and never enters the context.
  4. Scope per task: a triage agent reads the helpdesk and the contract, with no write tool in the ERP.
  5. A record of every access: who asked, which data was read and which source answered.

In the Company Brain, access control is inherited from the source system

The Company Brain connects ERP, HRIS, contract management and documents once and organises that data in a knowledge graph. Permissions come along with it. Each query carries the identity of whoever asked, and each source returns the slice that person already sees in the system itself.

There is no parallel control to maintain. In an M&A deal, the confidential project's documents are restricted to the project group in the repository. The FP&A agent receives only what the analyst who asked can already open, and when someone leaves the group, the change at the source applies to every agent.

The context is served to the model over MCP, already filtered, and every answer cites the source system and record. Security can reconstruct who asked, which sources were read and with which permission.

The Company Brain applying access control with permissions inherited from the source system before the model
In the Company Brain, access control is inherited from the source and applied before the data reaches the model

Brazil's data protection law (LGPD) calls for necessity and security in processing personal data

The LGPD limits processing to the minimum the purpose requires and demands measures against unauthorised access. An agent that reads medical records from the whole base to answer about one patient goes against both principles. Record-level access control, applied before the model, and a log of every query are the evidence of how the company handles this data.

Legacy systems and access reviews still require work

Inheritance is only as good as the source permission. Legacy systems with coarse profiles, where the whole finance team sees everything, need an additional rule, defined with the area that owns the data.

Inheriting also means inheriting mistakes. Periodic access reviews are still necessary and carry more weight, because the agent makes any access easier to exercise.

The first agent starts with sensitive data that has a clear owner

A good starting point is a case where access is already well defined at the source, such as confidential contracts in legal. Before connecting the agent, it is worth mapping which systems it queries, with which credentials and whether the identity of the person asking reaches each source. With that map, the first agent's access control rests on inherited permissions, and the following cases reuse the same connections and rules.

Get the next articles on AI governance and security