AI agents are becoming increasingly capable.
They can search information, reason across data, invoke tools, interact with applications and increasingly take actions on our behalf.
That creates tremendous opportunity.
But it also raises a question that I think deserves much more attention:
Just because an AI agent can access something, should it?
As we move from AI assistants that primarily generate responses toward agents capable of taking actions, Responsible AI increasingly becomes an architecture question—not just a model or policy question.
And one of the most important architecture decisions may be defining exactly what an agent can see, what it can do, and under what conditions.
Don't Treat the Agent as the Application
Consider a typical enterprise application.
The application may have access to:
- Public information
- Internal documents
- Confidential business data
- Personal or sensitive information
- Administrative services
- APIs capable of changing data
A common mistake would be allowing an AI agent operating within that application to inherit all of those capabilities.
Instead, I think agents should be treated as their own identities with their own access boundaries.
Enterprise Application
│
├── Public Data
├── Internal Data
├── Confidential Data
├── Sensitive / Regulated Data
└── Administrative Services
↓
AI Agent Access
Only what is required
for the specific task
The application boundary and the agent boundary don't necessarily need to be the same.
Think About Data in Layers
One practical approach is to classify information before deciding what an AI agent should be able to access.
For example:
| Data Layer | Example | Possible Agent Access |
|---|---|---|
| Public | Published information | Broad access |
| Internal | Policies, documentation | Controlled access |
| Confidential | Internal operational information | Role/task-based access |
| Sensitive | Personal, health, financial data | Highly restricted |
| Privileged | Credentials, security/admin data | Normally prohibited |
The exact classifications will differ between organizations.
The principle is more important:
AI access should follow data sensitivity—not technical availability.
If an agent technically can query a database, that shouldn't automatically mean it can query every table within it.
Separate "Can Read" From "Can Act"
Another important distinction is between information access and action authority.
An agent may reasonably be allowed to:
Read a record.
That doesn't automatically mean it should be allowed to:
Modify the record.
And being able to modify something doesn't necessarily mean it should be allowed to:
Delete, export or approve it.
Think of permissions progressively:
READ
↓
CREATE
↓
UPDATE
↓
EXECUTE
↓
DELETE / EXPORT / APPROVE
Risk generally increases as we move downward.
Higher-impact actions may require additional controls—or human approval.
Give Agents Their Own Identity
This is another area I think will become increasingly important.
Instead of an agent operating through broad shared application credentials, treat the agent as a distinct identity.
That allows us to answer:
- Which agent accessed the information?
- On whose behalf?
- What permission did it use?
- Which tool did it invoke?
- What changed as a result?
Without clear identity, accountability becomes difficult.
And Responsible AI without accountability is difficult to operationalize.
Tools Need Boundaries Too
Agents increasingly interact with tools:
Agent
│
├── Search
├── Database
├── Email
├── APIs
├── Workflow
└── External Systems
Giving an agent access to every available tool creates unnecessary exposure.
A better approach is to expose only the tools required for the agent's purpose.
For example, a knowledge assistant may need:
✓ Search documents
✓ Retrieve approved knowledge
✕ Send email
✕ Modify records
✕ Execute administrative actions
An operational agent may legitimately require additional capabilities—but those permissions should be intentional.
Guardrails Should Exist Outside the Prompt
We often think about AI guardrails as instructions:
"Do not access confidential information."
"Do not perform unauthorized actions."
Those instructions are useful.
But instructions are not authorization controls.
A stronger architecture looks more like:
User Request
↓
AI Agent
↓
Policy / Authorization Layer
↓
Approved Tool
↓
Approved Data / Action
The agent can request an action.
The surrounding system decides whether that action is permitted.
That separation becomes increasingly important as agents gain autonomy.
Human Oversight Should Be Risk-Based
Human-in-the-loop doesn't mean a person needs to approve every AI action.
That would remove much of the value of automation.
Instead, oversight can be proportional to impact.
Low Risk
Automatic
Medium Risk
Automatic + Monitoring
High Risk
Explicit Approval
Critical / Irreversible
Human Decision
For example:
Searching approved documentation may require no intervention.
Sending an external communication might require additional validation.
Changing sensitive information or executing an irreversible action may require explicit approval.
The goal isn't maximum human involvement.
It's appropriate human involvement.
Don't Forget Agent Memory
Agents may also maintain memory or state.
That introduces another data layer.
Questions worth asking include:
- What information can be stored?
- How long should it remain?
- Is memory isolated between users?
- Can sensitive information enter memory?
- Can malicious content influence future behaviour?
Memory shouldn't become an uncontrolled data store simply because it improves the agent experience.
Observability Becomes Part of the Guardrail
Preventive controls will never catch everything.
So we also need to understand what agents actually do.
Useful telemetry might include:
- Data accessed
- Tools invoked
- Actions attempted
- Actions denied
- Permission changes
- Unusual execution patterns
- Human approvals
- Final outcomes
This changes observability from simply:
"Is the AI available?"
to:
"Is the AI behaving within the boundaries we intended?"
A Simple Agent Guardrail Model
Putting these ideas together, I think about agent security in several layers:
RESPONSIBLE AI / GOVERNANCE
│
HUMAN OVERSIGHT
│
POLICY & AUTHORIZATION
│
┌───────────────┼───────────────┐
│ │ │
IDENTITY TOOL ACCESS DATA ACCESS
│ │ │
└───────────────┼───────────────┘
│
AI AGENT
│
MODEL / REASONING
│
MONITORING & AUDIT
No single layer provides sufficient protection.
The strength comes from combining them.
Responsible AI Is Also an Architecture Discipline
Responsible AI discussions often focus—correctly—on:
- Fairness
- Transparency
- Explainability
- Privacy
- Accountability
As AI becomes more agentic, I think another dimension becomes equally important:
Control.
Can we clearly define:
What the AI can access?
What it can do?
Under whose authority?
When a human must intervene?
And can we reconstruct what happened afterward?
Those are Responsible AI questions.
But they're also architecture, security and engineering questions.
Final Thoughts
As agents become more capable, I don't think the answer is to prevent them from accessing enterprise systems.
That would limit much of their value.
The challenge is designing access intentionally.
Give agents enough capability to accomplish their purpose—but not enough unrestricted authority to create unnecessary risk.
In other words:
The goal shouldn't be maximum AI access. It should be minimum necessary access with maximum accountability.
That may become one of the most important guardrails as organizations move from AI that answers questions to AI that increasingly takes action.
Top comments (0)