Your AI Coworker Has Three Doors Into Your Data. One Rule Must Hold at All of Them.

The Permission Check That Disappears at the Side Door

A customer record can be protected in your CRM and exposed through an export that uses a different login. The AI coworker did not need to break the rule; it merely took another route to the same data.

That is the useful idea behind Oracle's October 26 Deep Trust AI Architecture announcement. Oracle argues that policies defined only in an application can be missed when software accesses the underlying database directly through a connector or natural-language query. It describes enforcing end-user access and business constraints nearer the data, so the same rule applies regardless of the interface. This is a vendor's architectural announcement, not proof that every product or installation is automatically safe. The design problem it identifies, however, is immediate for a small team that has added AI to an existing stack.

Picture a service company with a scheduling app, a shared spreadsheet for dispatch, and a reporting database. A coordinator asks a scheduling Teammate to confirm tomorrow's jobs. Its approved role is to read job times and contact details for assigned customers. The CRM screen hides private notes about billing disputes. The nightly spreadsheet export includes those notes, and a reporting connector has access to the entire customer table. Which permission applies when the coworker chooses the spreadsheet instead of the CRM screen?

If the answer is “the instructions tell it not to look,” you do not have an access boundary. You have a request to behave. Instructions are useful for deciding how to work, but they cannot make a broad credential narrow or remove a sensitive column from an export. Structural controls must survive a change of route, a new model, and a mistaken choice of tool.

This piece is about AI coworker data access controls, specifically the gap between a policy displayed in one app and what the connected systems will actually allow. It is distinct from defining what a business metric means or deciding whether a person has a valid login. The question is whether the same business rule survives every technically permitted path to the underlying record.

Map the Data Routes Before You Assign the Coworker a Role

The first mistake is to inventory applications rather than paths. “The coworker has CRM access” is not a complete statement if it can also search documents, call a reporting API, open a downloaded CSV, or ask another Teammate for a summary of that CRM data. A permission review has to follow the information, not the app icon.

For one recurring job, draw a route map with five columns: entry point, executing identity, source, permitted data, and possible write. Start with the human request. Follow each tool call to the identity presented to the downstream service. Record whether that identity represents the requesting person, a dedicated Teammate, or a shared administrator. Then list copies, caches, exports, and summaries that can contain the same sensitive fields.

A scheduling role might have these routes:

• CRM API: a named service identity reads assigned appointments and approved contact fields.
• Spreadsheet: a shared document contains appointment data plus unreviewed billing notes.
• Reporting warehouse: a general-purpose account can query historical customers across regions.
• Messaging channel: a colleague can forward a summary into a team conversation with a different audience.

The second and third routes are not safe merely because the first is well configured. Nor is a downstream summary harmless because it omits the original row identifier. A private billing dispute can still be recognized in a sentence about a named customer. That is why shared AI coworker memory needs separate audience boundaries, even after source access is fixed.

Separate requester, executor, and source identity

A person may be entitled to see a record without authorizing an AI coworker to use it for every purpose. The Teammate may have a dedicated login that cannot impersonate that person. A connector may use one broad service account for everybody. These are three different authorization stories; collapsing them into “the user has access” conceals the real exposure.

Write down who requested the task, which credential reached the source, which customer or business unit was in scope, and which permission decision was made at the source. If the source only sees a shared administrator credential, a prompt that says “act for Morgan” does not provide Morgan's source-level permissions. Do not claim user-level authorization unless the downstream system actually receives and validates that context. The distinction between a valid login and authority for a particular action remains essential here.

A smaller company does not need an enterprise identity program to begin. It can give a scheduling role a separate read-only account, limit it to a controlled view, and remove access to the raw export. If the platform cannot restrict a field or record by role, put an approved intermediary in front of it that returns only the fields required for the job. Document the gap rather than calling a broad account least privilege.

Enforce the Rule Where Every Route Has to Pass

A rule in a Teammate's instructions says what work should be done. A rule at an enforcement point decides what work can be done. The latter needs to cover the available routes, not just the preferred interface. Which layer is appropriate depends on where your business data actually lives.

If a CRM is the authoritative system, prefer its own field, record, and role permissions plus a scoped API over a full-account export. If you control an API, expose a task-specific operation such as “list tomorrow's assigned appointments” rather than arbitrary customer-table access. If you control a database, database-enforced policies and constraints can make a mistaken query fail before it returns data or changes a row. If a vendor's CSV export ignores the primary system's restrictions, stop treating the export as an equivalent safe route.

PostgreSQL's row-security documentation illustrates both the strength and the caveat. Row-level security can restrict which rows normal queries and modifications reach. But table owners normally bypass it, and superusers or roles with BYPASSRLS always do. A service account that owns the table can quietly defeat the policy that looked airtight in a test under a less privileged login. “Turn on row security” is not a complete operational plan; verify the actual identity the connector uses.

Source-level controls also do not solve every problem. A database constraint can reject an unauthorized update in that database, but it will not revoke a previously downloaded CSV or prevent a human from pasting an approved record into the wrong chat. An API can filter fields, but a cached result may still be retained too long. Decide which source is authoritative, then trace every copy and downstream use. Your policy is only as strong as the least controlled path that remains open.

What good and bad look like in a purchase request

Suppose an operations lead asks a purchasing Teammate to prepare replacement equipment orders under a department budget. Bad: the Teammate's instructions say “never exceed the spending limit,” while its connector holds a general purchasing credential. It drafts a compliant order in a review screen, then submits a higher amount through a second integration that does not check the limit. The prompt was clear; the write path was not.

Good: the Teammate can propose an order using a scoped identity. The purchasing system independently checks the department, requester, amount, and approval state at submission. An order above the limit is rejected there, even if the Teammate uses another approved interface. A named person reviews exceptions. The decision record notes who requested the purchase, what changed, and which control permitted or denied it.

Oracle's announcement gives a database-level example of rejecting charges above an employee limit. That is a useful illustration of the principle, not a suggestion that a small business must adopt Oracle's database to do purchasing safely. Many teams can express the same invariant through an existing purchasing service, a transaction-validated API, or a controlled approval workflow. The key is that the final system of record must enforce the rule independently of the prose that asked the coworker to follow it. For purchase-specific authority, see how to define exactly what an AI coworker may buy.

Run a Side-Door Test Before You Expand Access

You can make the boundary concrete in a week without rebuilding your entire stack. Pick one recurring workflow and one sensitive field or business rule. Do not start with a general audit of every AI use in the company; a narrow, repeatable test will expose where the role definition and the technical permissions diverge.

1. Name the business invariant. For example: “The scheduling role may not read customer billing notes,” or “Only an approved purchasing request may change an order above the department threshold.” Write it in terms a human reviewer can check, not in vague language such as “respect privacy.”
2. List every route. Include the primary app, connectors, direct API and database access, exports, shared files, automation history, cached searches, and another Teammate's summaries. Record the credential used at each hop.
3. Mark the enforcement point. For each route, say where the rule is enforced: source permission, task-scoped API, reviewed export, write-time validation, or nowhere. “The prompt says no” belongs in the nowhere column for access-control purposes.
4. Remove avoidable alternate paths. Revoke unnecessary direct table access, replace broad exports with restricted views, and avoid reusing a human administrator credential. Keep a documented owner for the controlled path.
5. Test a denied read and a denied write. Use a harmless test record and a non-production or reversible change. Try the normal route and an alternate route with the same identity the Teammate actually uses. Confirm the source rejects the disallowed operation; do not rely solely on the Teammate declining to attempt it.
6. Check the evidence and the copy. Verify logs identify the requester, executing identity, source, decision, and time. Search for old exports or caches that still disclose the test field even though the live API is fixed.
7. Set a change trigger. Repeat the test when a new connector, Skill, model provider, shared folder, data export, or role is introduced. Assign one person to approve those route changes and another to review failures where practical.

This is seam design in operational form. A Teammate can gather and prepare work inside a defined boundary; the authoritative service can reject out-of-scope actions; a person handles the exception. If the boundary cannot be enforced, reduce the role's reach until it can. That is safer than attaching a broad credential and hoping the model consistently chooses the right door.

The test should produce an artifact: a one-page route map, the rule and its owner, the results of the allowed and denied cases, and a date for the next check. If a test fails, the response is specific: close that route, narrow that identity, or move the control into a system that all permitted routes must traverse. Rewording the Teammate's instructions can help it reason about the task; it does not close the path.

FAQ

Q: Are prompts enough to keep an AI coworker from seeing private data?
A: No. Prompts shape behavior but do not reduce what a connected credential can read. Enforce sensitive-field and record boundaries in the source system or a restricted intermediary, then test with the actual runtime identity.

Q: Does row-level security solve AI coworker data access by itself?
A: It can protect rows for covered database queries, but it does not protect uncontrolled exports or all downstream copies. Privileged and owner identities may bypass policies depending on the database setup; verify the account actually used and the separate controls on files and APIs.

Q: What if our CRM has no field-level permissions?
A: Return a limited, approved view through a separate service or export process, and deny the coworker access to the unrestricted source. If neither can be done, keep the sensitive workflow with a human rather than pretending instructions are a technical restriction.

Q: Should each Teammate get its own service account?
A: Separate identities make scope and attribution easier, but the right unit depends on the system and task. Avoid a shared administrator credential; give each role only the operations it needs and record the human requester separately where delegation matters.

Q: How do we know the same rule holds through multiple integrations?
A: Test a permitted case and a denied case through each route using the real execution credentials. Check the source's decision and the downstream copy, not just the AI's final answer. Repeat when routes or role permissions change.

Associates AI Teammates gives you a model-agnostic platform for configuring persistent AI coworkers with defined roles and controlled connections. Explore the platform and get started when you're ready to build a team whose work stays inside the boundaries your business sets.