What about security and data in an agentic system?

In the systems where it already lives. The agentic layer doesn't become a second company database: it reads from the source system when it needs a data point and writes the result back there. What the layer keeps on its own is what is needed to operate and to audit: the state of each case, the audit log, and the bounded memory the process requires.

The code of the system we build lives in your repository and your infrastructure, not ours. That means you control where it runs, who has access and how long each thing is kept. Deployment and retention details are defined per project, according to your policy and your sector.

Only what the core hands it for the task at hand. This is the part that raises the most questions, and the right answer is a design principle: minimize. If classifying a document doesn't require the full home address, the address doesn't travel to the model. If a sensitive value can be replaced with a reference, it is.

Points worth putting in writing on every project:

• Which models and providers are involved, and under what contractual terms for data use and retention.
• Which categories of data are never sent to an external model.
• Where model inputs and outputs are recorded, and who can see them.

Those terms come from the contract with each provider and your company's policy. You review them, and we review them with you before building.

• One per agent and per system. If one is compromised, it is revoked without affecting the others.
• Outside the code and outside the instructions. They live in a secrets store and are never placed in text the model reads, because what the model reads can end up in a response.
• With expiry and rotation. They are renewed on a defined schedule and when the people who administer them change.
• Never visible to the model. The connector uses them. The model only asks for the action.

That the agent never sees the key isn't a detail. It is what keeps a malicious conversation from talking the agent into handing it over.

Beyond the ones every piece of software has, there is a characteristic one: the agent reads text from outside sources (an email, a document, a customer's reply), and that text can carry disguised instructions. It is called prompt injection. The defense isn't asking the model to "not be fooled". It is designing so that fooling it gets an attacker nothing:

• The agent can only run the connector's closed catalog, so a malicious instruction finds no dangerous actions to trigger.
• Sensitive actions require human approval, and the person sees where the proposal came from.
• External content is treated as data, not as orders, and is marked untrusted inside the core.
• Limits (amounts, recipients, volumes) are validated in code, outside the model's reach.

It is the same principle as governance: don't depend on the model behaving, build so the system doesn't need it to.

Each company has its own space: its data, its credentials, its agents and its audit log, shared with no one else. When one component serves several organizations, isolation is enforced in the database and tested with the application's own credentials, not an administrator account that bypasses the rules. A test that uses the owner's access can pass even when isolation is broken.

• What data leaves my systems, where does it go, and for how long?
• Which credential does the agent use in each system, and how do I revoke it?
• Where are the limits: in code, or only in the instructions?
• What happens if the model receives a malicious instruction inside a document?
• Can I see the full audit log, and can I stop an agent myself?
• Where does the code live, and what happens if we stop working together?

If a vendor can't answer those six precisely, the conversation is incomplete. For the overview, go back to the guide. For general questions, see the FAQ.

This page describes our design approach. It doesn't replace a security review or legal advice on your sector's obligations, which belong to your specialists.