Your data: infrastructure, permissions and privacy

Context

Before an agent does its first task, someone decides what it can see. Most of the time nobody makes it. Someone installs the tool, opens the whole mailbox because it is faster, and nobody looks again.

You do not hand an intern the bank password on day one. You give access to what the job needs and widen it as the person shows judgment. The same applies to an agent, with one difference: it works fast and at any hour, so an extra permission travels further before anyone notices.

This lesson gives you four decisions worth writing down before installing any agent, whether it comes from Omni Agent or from another vendor.

The core idea

An agent is only as safe as the access decisions you made about it. There are four:

1. What data it sees. Invoices, email, contracts, payroll. Each source is a separate decision.
2. With what permissions. The minimum needed. Reading is not the same as writing, and writing is not the same as sending an email or releasing a payment.
3. Where it runs. On shared infrastructure alongside other customers of the vendor, or on dedicated infrastructure used only by your company.
4. Which model provider processes what. The agent thinks with a language model that a third party operates.

The fourth deserves an honest note. When the agent reads an invoice and asks the model to interpret it, that text travels to the model provider and is processed there. This is why, if the agent uses a model operated by a third party, no vendor can promise you that your data "never leaves". What you can decide is which data you send, under which account and on what terms. Read those terms: how long the provider keeps what it receives, whether it uses it to train its models, and where it processes it. They change over time, so the right source is the provider's current documentation, reviewed with your legal team.

How it is done

A simple process for any new agent:

• Take inventory. List the sources the agent needs for its task and nothing more.
• Classify each source. Public, internal or sensitive, such as payroll, health or personal financial data.
• Give it its own account. Do not use yours, because then you cannot tell what it did and what you did.
• Start read-only. Let it propose and a person execute. Widen permissions once the work has proven reliable.
• Mark what requires human approval. Sending to a customer, paying, deleting. A person always approves those three actions.
• Ask for a log. A record of what it opened and what it did, readable without a technical background.
• Review every quarter. Permissions pile up. Remove the ones that are no longer needed.

On where it runs. On shared infrastructure, several customers use the same machines and sometimes the same agents. On dedicated infrastructure, as we understand it at Omni Agent, each customer has its own virtual machine, its own Anthropic account and its own agents, with nothing shared. That gives isolation and control, but the model still processes whatever is sent to it.

On the law. In Mexico, the Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) governs how a company handles personal data. According to the current text of the law, published in the Diario Oficial de la Federación, in broad terms it asks for a privacy notice that says what you use the data for, consent (with extra care when the data is sensitive), reasonable security measures and respect for the rights of access, rectification, cancellation and objection. An agent that reads customer email is handling personal data. This is general orientation, not legal advice: ask your attorney whether your privacy notice already covers the use of agents.

Questions for any vendor, ourselves included:

1. Which of my data does the model receive, and which stays out.
2. Who is the model provider, and what do its terms say about retention and training.
3. Does my information share a machine, an account or agents with other customers.
4. What permissions does the agent ask for, and which are optional.
5. Where does the log live, and who reads it.
6. What happens to my data and my access if I end the contract.
7. How will I be told if an agent makes a mistake.

An illustrative case

Imagine a mid-sized distributor, invented for this example, that wants an agent to help with bank reconciliations. The numbers are invented too: three accounts and about forty invoices to review each week.

The finance director makes the decisions in writing. The agent sees the bank statements and the supplier invoices. It does not see payroll or staff files. It has its own user, read-only, and its job is to propose which transaction each invoice belongs to. It cannot send payments or write to suppliers. The accountant approves every proposal before it is recorded.

In the third week the agent matches an invoice to a similar-looking deposit by mistake. The accountant catches it in her review, corrects it and leaves a note in the log.

Months later, with trust earned, the director extends its scope to two more accounts. The accountant no longer keys in reconciliations and spends that time reviewing exceptions and talking with suppliers. Her role grew, and the agent's permissions grew with it, one at a time.

Takeaways

• Before installing an agent, decide in writing what data it sees, with what permissions, where it runs and which model provider processes what.
• Give the minimum needed and widen with evidence. Start read-only.
• Sending, paying and deleting always go through a person.
• The provider's model processes what it is sent. Read its terms on retention and training, together with your legal team.
• The LFPDPPP applies when the agent touches personal data. Review your privacy notice with your attorney.
• Put the seven questions to any vendor.