Why is a read-only role not enough?

Because reads leak, joins exfiltrate, and a role cannot tell a routine query from a dump of the customer table. Policy at the action level, with masking on flagged columns and a record of every access, is what a read-only role was standing in for.

How do agents and copilots connect?

Through Datapace, over MCP, to the confirmed graph and the actions the policy allows. They do not hold database credentials. How Datapace itself connects to your databases, and where it runs, are decisions taken with each partner.

What does the security posture look like?

Deployment, access, and data handling are designed with each partner, engagement by engagement, in its jurisdiction’s terms. The product’s own commitments are the ones on this page: policy on every action, approval on the risky ones, governed context, and a complete audit trail.

Security for databases that people and AI agents both work on

Copilots and agents are already reaching for production data, and a read-only role is not a policy. Datapace is the layer they reach through: every action is checked against the policy your team sets, the risky ones wait for a person, and copilots, BI, and agents read the confirmed graph over MCP instead of holding a raw connection. Which databases and environments Datapace itself may read is agreed with your team before anything connects.

Today. Agents and copilots holding database credentials, with a read-only role standing in for a policy and no record of what they touched.

With Datapace. Every action checked against your policy, the risky ones held for approval, and every AI system reading governed context through one gate, all of it in the audit ledger.

What Datapace does here

Policy on every action: Your team defines what agents and people may do per database and environment; Datapace checks every statement against it before it runs and blocks the rest.
Approval on the risky ones: Writes, schema changes, and anything outside routine pause for a person; routine reads proceed, so the policy is not a bottleneck.
Scoped access, agreed first: Which databases and environments Datapace may read is decided with your team before anything connects, designed as read-only, approved scope.
Governed context, not raw access: Copilots, BI, and MCP clients reach the confirmed graph through the same gate, never a raw connection, and see masked values on flagged columns.
Every decision recorded: Allowed, held, or blocked, each decision lands in the audit ledger with the actor, the statement, and the policy that decided it.

Questions teams ask

Why is a read-only role not enough?: Because reads leak, joins exfiltrate, and a role cannot tell a routine query from a dump of the customer table. Policy at the action level, with masking on flagged columns and a record of every access, is what a read-only role was standing in for.
How do agents and copilots connect?: Through Datapace, over MCP, to the confirmed graph and the actions the policy allows. They do not hold database credentials. How Datapace itself connects to your databases, and where it runs, are decisions taken with each partner.
What does the security posture look like?: Deployment, access, and data handling are designed with each partner, engagement by engagement, in its jurisdiction’s terms. The product’s own commitments are the ones on this page: policy on every action, approval on the risky ones, governed context, and a complete audit trail.

Go further

See this on your own data

Bring a use case. We will show you what Datapace reads on your live database, what your experts would confirm, and what the agents would propose first.

Book a call