If you let an AI agent read your customer database, does that mean you should also let it update customer records?
It sounds like a simple question. Yet many discussions about AI agents treat access as if it's one big switch: connect the system, grant permissions, and let the agent get to work.
That's convenient for demos.
It's not a great way to protect a business.
Reading a record and changing it are fundamentally different operations. Looking up an invoice doesn't have the same consequences as issuing a refund. Checking inventory is not the same as adjusting stock. Finding a customer is not the same as deleting their account.
An AI agent should not automatically inherit every capability of the system it can access.
The better approach is to give it exactly the permissions needed for its job, with additional controls for actions that can change or destroy data.
The everyday problem with broad access
Imagine a growing e-commerce business.
The support team spends a lot of time answering questions such as:
- Where is my order?
- Has my payment been received?
- Is this item in stock?
- When was my last purchase?
The company decides to introduce an AI agent so support staff can ask these questions in natural language rather than opening several administration screens.
The agent needs to look up orders, check payments, and retrieve inventory information.
So far, so good.
But the company connects the agent using an account with broad database permissions. That account can also modify order records, update inventory quantities, and delete customer information.
Why grant all those capabilities when the immediate job is simply answering questions?
The agent might not intend to change anything. But permissions should not depend on what the model intends to do.
If the agent is manipulated, misunderstands a request, or makes a bad decision, its available permissions determine some of the consequences.
This is why secure AI integrations should start with a basic principle: access to information does not automatically imply permission to change it.
Start with what the agent actually needs
Before connecting an AI agent to a business system, identify its intended responsibilities.
An agent designed to answer order-status questions might need to:
- Search orders using authorized identifiers.
- Read shipment status and tracking information.
- Retrieve relevant delivery dates.
- Summarize results for the support team.
It probably doesn't need to:
- Delete customer records.
- Change payment information.
- Issue refunds.
- Modify user permissions.
- Run arbitrary database updates.
That distinction should be reflected in the actual tools and credentials available to the agent.
A prompt saying “only answer questions; never modify data” is useful guidance, but it should not replace read-only access controls.
If the agent has access only to approved read operations, a mistaken decision cannot directly turn into an unauthorized database write through those operations.
This is one of the simplest ways to reduce the potential impact of an AI agent failure.
A database example: read-only really should mean read-only
Suppose a team connects an AI agent to PostgreSQL.
The team wants employees to ask questions such as:
“How many orders did we receive today?”
“Which products are running low?”
“Show me the customers whose orders haven't shipped.”
These are primarily read operations.
One tempting approach is to provide a database credential with broad privileges and instruct the model to generate safe SQL.
That introduces unnecessary risk. The model might generate an unintended UPDATE, DELETE, or other statement. A prompt injection could also encourage it to attempt an operation unrelated to the user's request.
A safer architecture gives the agent a database role that can read only the necessary tables or views. Where appropriate, it can use carefully defined queries or tools that expose specific business operations instead of unrestricted SQL.
If the business later decides that the agent should update inventory, that capability can be introduced separately, with its own authorization rules and validation.
This is the difference between adding a controlled capability and handing over general access.
For teams exploring AI agents for PostgreSQL, the principle is straightforward: use database permissions as a real security boundary, not just as a suggestion to the model.
Write access should be earned, not inherited
Read-only access is a useful starting point, but many business agents eventually need to do more than answer questions.
They might create draft invoices, update shipping details, or change inventory quantities.
That's where a layered permission model becomes valuable.
Instead of treating an agent as either read-only or fully privileged, divide its capabilities into meaningful categories.
Read: Retrieve authorized information.
Draft: Prepare a proposed change without applying it.
Limited write: Perform specific, constrained updates.
Sensitive action: Execute operations that require additional validation or approval.
Destructive action: Delete records or perform other high-impact operations under strict conditions.
These categories don't need to be identical for every company. They should reflect the business's actual risks and workflows.
For example, an inventory agent might be allowed to read stock levels and prepare a proposed adjustment. A user with the right permissions could approve the change. The application would then validate the exact product, quantity, and reason before updating the inventory system.
The model helps coordinate the process, but the application retains control over what can happen.
This is a more flexible approach to AI-powered workflow automation than giving every agent the same unrestricted account.
Don't confuse tool availability with user authorization
There's another important distinction.
An agent might have access to a tool, but the person interacting with it might not have permission to use that tool.
Imagine a business where a customer support representative can view orders but cannot issue refunds above $50. A finance manager, on the other hand, can authorize larger refunds.
Both employees may use the same AI assistant.
The assistant should not grant the support representative additional privileges simply because the refund tool exists.
The application must check the acting user's permissions whenever an action is requested. It should also validate the arguments and any applicable business rules.
A safe system doesn't ask only, “Can this agent call the refund tool?”
It asks, “Can this person authorize this specific refund, for this order, at this amount, under these conditions?”
That is a much stronger foundation for permission-aware AI agents.
It also prevents an important class of mistakes: letting a general-purpose agent become a shortcut around the existing access controls that the business already relies on.
What about human approval?
Approval becomes more useful when it sits on top of a sensible permission model.
If an agent can perform every operation with a powerful credential, a human approval step may become the only barrier between a mistaken proposal and a serious consequence.
But if the agent has narrowly defined capabilities, the system already has meaningful restrictions before approval enters the picture.
For example, a low-risk update might be allowed automatically for an authorized employee. A larger inventory adjustment might require a manager's approval. Deleting an important record might be prohibited entirely or restricted to a separate administrative workflow.
The approval must apply to the exact operation and arguments being authorized. If those details change, the application should not silently reuse the earlier approval.
And if the approving person lacks the necessary authority, the operation should remain blocked.
Human approval is a valuable additional control, not a replacement for permissions.
The challenge of connecting existing software
Businesses often have years of investment in their current systems. Their databases, CRMs, ERPs, and internal tools already contain the workflows and information their teams need.
They don't necessarily want to replace all of that just to introduce AI.
That makes permission design even more important.
A useful approach is to expose existing system capabilities through narrowly defined tools, use appropriate credentials, and enforce permissions at the point of execution.
For example, Caterfli is designed to connect existing APIs, databases, and MCP servers to AI agents, allowing teams to work with their systems through natural-language interaction.
When implementing that kind of architecture, avoid assuming that connecting a system means giving the model unlimited authority over it.
Instead, identify which operations should be available, which users can invoke them, and which actions require additional checks.
For database connections, use database-level privileges wherever possible. For API connections, prefer credentials and endpoints with the smallest practical scope. For MCP tools, review which capabilities are exposed and what permissions govern their execution.
The goal is to make existing software easier to operate without weakening its security model.
A practical checklist before granting write access
Before giving an AI agent permission to modify a system, ask these questions:
- Does the agent genuinely need write access for its assigned job?
- Can the required operation be exposed as a narrow, well-defined tool?
- Are the credentials restricted to the necessary resources?
- Are user permissions checked independently of the model?
- Are arguments validated against schemas and business rules?
- Are sensitive operations subject to appropriate approval?
- Can the application detect changes between approval and execution?
- Are important actions logged and their outcomes verified?
- Can the access be revoked without disrupting unrelated workflows?
If several answers are unclear, start with read-only access and expand the agent's capabilities gradually.
Test the new permissions with both normal requests and deliberately hostile or unexpected inputs.
The aim is not to eliminate every possible failure. It's to ensure that a failure in one layer doesn't automatically become a failure of the entire system.
The future of AI agents should not be all-or-nothing
There's a tendency to think of AI capability in terms of how much an agent can do.
Can it access the database? Can it update records? Can it run workflows without human intervention?
But capability is only half the question.
The other half is whether the agent has the right level of authority for the task.
An agent that can answer inventory questions, prepare proposed changes, and request approval for significant adjustments may be far more useful to a business than an unrestricted agent that can modify everything.
It may require a little more design work at the beginning. That's true.
But it also creates a clearer security model, a better audit trail, and fewer opportunities for a small misunderstanding to become a major incident.
My advice is to begin with the smallest set of permissions that makes the agent genuinely useful. Then expand those permissions based on actual needs, with appropriate safeguards for each new capability.
Read access lets an AI agent understand your business. Write access lets it change your business. Treat those as two separate decisions.
Top comments (0)