If an AI assistant needs to answer a question about one customer, it should not automatically be able to see every customer. That sounds obvious until a team connects an assistant to the account system using a single all-access credential. On October 13, TechCrunch named CedarDB among its 2026 Startup Battlefield Top 20. The company’s pitch includes a useful idea for business leaders: restrict what an agent can read or change where the records live, rather than relying on a prompt asking it to behave.

In brief: Before you ask an agent to work with live customer information, give it a named job and the smallest set of records and actions that job requires. Test those limits with someone who owns the underlying business process. The teams that learn to grant narrow access can build habits around real work; the teams that cannot will keep arguing about whether the assistant is safe enough to connect at all.

The question behind the demo

Picture a service manager who wants an assistant to prepare a morning list of overdue customer cases. A demonstration with a sample spreadsheet is easy. A live connection is different. The case system may also contain payment issues, private contact details, staff notes and accounts belonging to another region. If the assistant uses the same broad access as an administrator, the instruction “only look at overdue cases” is a request, not a boundary.

This is an illustrative scenario, not a reported CedarDB customer deployment. No demo proves what would happen with your records. You need to know whose identity the assistant uses, which records it can reach, whether it can change anything, and how a manager would discover a mistake. Those are management questions, not a request to become database specialists.

CedarDB says its system can use database roles and row-level policies to constrain what each agent can read or change. In plain terms, a role defines the kind of access a worker has; a record-level rule can prevent that worker from seeing information outside its assignment. CedarDB is selling a database, so its performance and safety claims need testing in a real environment. TechCrunch’s listing is evidence that the company was selected for a startup competition, not proof that this approach has delivered outcomes for every customer.

The principle travels farther than the product. Your team may already have ways to restrict access in the systems it owns. The task is to find out whether those restrictions still hold when an assistant, not a person at a screen, requests the information.

Two teams, same assistant

Consider two organizations that buy access to the same AI assistant. One connects it with a shared account that can read broadly. Security objects. The pilot stays on copied files, and nobody can say what would have to change before the assistant touches live cases.

Across the table, the other team starts with the manager’s overdue-case list. The assistant can read cases in that manager’s queue, but it cannot change a record or contact a customer. The manager compares the draft with the case system and logs what it missed. Now there is something to diagnose if the test fails, and a set of permissions to reuse if it works.

The model is the same. What changes is whether anyone can make an assignment small enough to test. Without that, the argument over AI risk goes in circles while the work stays on a sample spreadsheet.

This is not an argument to let every employee attach an agent to production records. It is an argument to make the permission conversation concrete. A team that can name the records, the permitted action and the person accountable for the result has something a generic AI policy cannot supply.

Try one access test before the purchase decision

Ask the owner of a routine process to bring one task that involves company records. Write down exactly what the assistant would need to see to complete a draft, and what it must never change. Keep the first test read-only. Give the assistant an identity that belongs to the task, not a borrowed employee login, then ask your technical lead or vendor to demonstrate the boundary with actual representative permissions. A sample file alone will not answer whether the live system enforces them.

Try a case the assistant should be allowed to retrieve. Then try one it should not: another region, another customer, or a restricted field in the same account. The test passes only if the underlying system denies the second request, even when the request is phrased persuasively. Finally, have the process owner compare the permitted output against the source records. A safe boundary does not make an answer correct.

Ask the vendor where the denial is enforced. Is it in the system holding the records, in an access layer with equivalent controls, or merely in the assistant’s written instructions? Ask who can change the permissions, how changes are logged, and what happens if the assistant is given a broader job next month. If nobody can show you the blocked request, you do not yet have the evidence to expand access.

The agentic organization needs assignments with a visible owner and a boundary that survives a bad instruction. CedarDB’s appearance on a list of 20 startups is a reason to ask a less glamorous question than “What can the agent do?” Ask what it cannot do. Then have someone try to cross that line in your own systems before you widen the job.

Research and draft: Mai. Editorial direction: John Lipe.