DataTugPull more from your data
Open app
☰

For engineering leads and platform owners

Production data access for people and AI agents

Support engineers, contractors and coding agents all need to look at real data. DataTug Perimeter is designed to give each of them exactly the access the task needs, under one set of rules, instead of a shared password and a promise.

Explore the demo project All five solutions

Starts here: DevelopersAI agent buildersHelpdeskSRE and on-call+3 roles

Also useful: Data analysts (also useful)

Watercolor of a harbour master raising a gate bar to let one tugboat through, beside cargo crates under tied-down tarpaulins and an open ledger on the gatehouse desk.
Illustration

An agent investigates order 11045 inside the Perimeter

  1. Agent asksWhy is order 11045 not shipped yet?
  2. Perimeter checks scopeOrders, Payments: read allowedOK
  3. ResultContactEmail •••@•••.ca maskedneeds attention
  4. Agent requests a changeRebook carrier for order 11045 onlyneeds attention
  5. Sarah approvesThis one order, for 15 minutesOK
  6. AuditWho asked, what ran, who approved
Static illustration of the intended flow, not a capture of the product. Perimeter is in development; masking, approvals and the audit trail shown here are planned.
Watercolor of identical brass keys hanging on a long row of hooks along a quay wall, and one more left in the pocket of a coat on a bench.

The problem

A support engineer needs one row to answer a customer. The quickest way is the application’s own login, which can also write. An AI coding agent needs the same row, so the connection string goes into its config or its prompt. Two weeks later nobody can say who read the customers’ emails, and the write access granted “for the incident” is still there.

Teams then build two systems: database roles and a VPN for people, and a separate gateway or a hand-made read-only replica for agents. The rules drift apart, masking is done twice or not at all, and neither side has one audit trail.

Before and after

Who: Engineering leads and platform owners

Today

4 tools2 hand-offs1 shared password

  1. Support engineer and an AI agent · SQL clientA shared read-write login is pasted into a SQL client, a chat or an agent’s config.a password changes hands
  2. Anyone who can connect · SpreadsheetSensitive columns are visible to everyone who can connect, or the data is copied and scrubbed by hand.
  3. Platform owner · Access ticketWrite access is granted for the whole incident and rarely taken back.
  4. Security review, afterwards · Database logsAfterwards nobody can list what was read, what changed and who agreed to it.
Today4 tools · 2 hand-offs · 1 shared passwordA shared read-write login is pasted into a SQL client, a chat or an agent’s config.Sensitive columns are visible to everyone who can connect, or the data is copied and scrubbed by hand.Write access is granted for the whole incident and rarely taken back.Click to see

With DataTug

1 workspace1 hand-offno shared password

Some steps are planned or in development.

  1. Policy ownerReads are read-only by default, and access policies limit which sources, tables and fields may be read. Today those policies are local CLI policy files.Access policiesAvailable
  2. People and agentsPeople and agents are meant to reach data through one Perimeter: reads scoped to the tables the task needs, and an agent acting for a person never allowed more than that person.DataTug PerimeterIn development
  3. The server, before a screen or modelSensitive fields are to be masked on the server, before a value reaches a screen or a model.Meaning-driven masking on the serverPlanned
  4. One person approvesA change becomes a request: a person approves one narrowly scoped, time-bound action, and only that action runs.Approve an investigation stepPlanned
  5. Everyone, one trailEvery read, request and approval is to land in one audit trail you can read, for people and agents alike.Audit trail merged with provenancePlanned
With DataTug1 workspace · 1 hand-off · no shared passwordReads are read-only by default, and access policies limit which sources, tables and fields may be read. Today those policies are local CLI policy files.People and agents are meant to reach data through one Perimeter: reads scoped to the tables the task needs, and an agent acting for a person never allowed more than that person.Sensitive fields are to be masked on the server, before a value reaches a screen or a model.Click to see

Each step names the part of DataTug it relies on and that part’s status today. “Planned” and “In development” steps describe where the product is going, not what you can use now.

Today’s access policies are enforced by your local DataTug CLI: an agent that can read your machine’s DataTug configuration could get past them. Server-enforced access through one Perimeter is in development. How access policies work

One Perimeter, not two products

A person in the web app and an agent connected through the CLI or an MCP server are two identities acting on the same data. Perimeter is meant to apply the same policies, the same masking and the same approvals to both, and to write both into the same audit trail. A rule changed once is changed for everyone.

Its limits are part of the design. A Perimeter protects only the access that goes through it: an agent that also holds the database password can go around it, so the design keeps the credentials with DataTug, not with the agent. Running DataTug on your own machine does not keep data away from a model hosted in the cloud; that is why masking is planned to happen before a value reaches the model. Today’s released part is read-only access by default and local CLI policy files; the rest of this page is in development or planned, as each step is marked.

Where it meets the other solutions

Try it on sample data

The public demo project opens in the browser with sample Northwind and Chinook data. No sign-up.

Explore the demo project