We spent years learning how to manage software robots. Now we are creating a new generation of autonomous digital workers—and many organisations don’t know what they can actually do.
There is a strange moment happening in enterprise technology.
We are surrounded by announcements about AI agents.
Agents that write code.
Agents that investigate incidents.
Agents that browse the web.
Agents that query databases.
Agents that operate cloud infrastructure.
Agents that send emails, create tickets, modify documents, call APIs, use MCP servers, delegate work to other agents, and sometimes create new workflows themselves.
The technology is moving incredibly quickly.
But there is a question that isn’t being asked nearly enough:
How many AI agents are actually operating in your organisation, and what can they do?
For many organisations, the honest answer may be:
We don’t know.
And that could become one of the biggest technology governance problems of the next few years.
We have seen this movie before
There was a time when enterprise automation meant scripts, macros and scheduled jobs.
Then came Robotic Process Automation.
RPA introduced a powerful idea:
Software robots can perform work previously performed by humans.
Organisations began deploying bots across finance, customer service, operations, HR, IT and back-office processes.
The scale became significant.
Automation Anywhere, for example, reported more than 2.6 million bots deployed worldwide in 2020.
Suddenly organisations had thousands—or sometimes tens of thousands—of digital workers.
And companies had to learn how to manage them.
They created:
- Bot inventories
- Central orchestration
- Credential management
- Access controls
- Monitoring
- Audit trails
- Change management
- Business ownership
- Governance processes
Eventually, organisations learned an important lesson:
You cannot govern automation that you cannot see.
Now the bot is becoming an agent
The fundamental difference is that RPA bots were generally designed around predefined workflows.
Consider a simplified RPA process:
Open application
↓
Read customer record
↓
Enter information
↓
Save
↓
Finish
The workflow was explicit.
The agentic model is different.
Receive objective
↓
Understand objective
↓
Plan
↓
Choose tools
↓
Execute
↓
Observe result
↓
Adapt
↓
Continue
The agent may have access to a growing collection of capabilities.
For example:
┌── Filesystem
├── Shell
├── Browser
├── GitHub
Agent ──────────────┼── Database
├── Slack
├── Email
├── Cloud APIs
├── MCP servers
└── Other agents
Now ask yourself:
What exactly is the asset you’re trying to govern?
The agent?
The model?
The prompt?
The tools?
The MCP servers?
The credentials?
The infrastructure?
The workflow?
The combination of all of them?
The answer is increasingly:
All of it.
The automation explosion is becoming harder to see
This is where the comparison with RPA becomes interesting.
RPA gave organisations a relatively visible unit:
The Bot
Agentic AI gives us something much less predictable:
The Agent + Model + Prompt + Tools + Memory + Identity + Workflow + Infrastructure
And these components can change independently.
A developer can add a new tool.
Someone can connect an MCP server.
A prompt can be modified.
A model can be replaced.
A workflow can gain another agent.
A new API credential can appear in the environment.
A previously read-only agent can suddenly gain write access.
None of these changes necessarily looks like a traditional application release.
But the agent’s capability may have changed dramatically.
The problem isn’t the number of agents
It is tempting to ask:
“How many agents do we have?”
That’s useful.
But it isn’t enough.
Imagine two organisations.
Organisation A
100 agents.
Most can:
- Read documents
- Summarise information
- Answer questions
Organisation B
10 agents.
Each can:
- Access production databases
- Execute shell commands
- Browse external websites
- Access GitHub
- Send emails
- Call cloud APIs
- Read secrets
- Modify infrastructure
- Delegate tasks to other agents
Which organisation has the greater AI risk?
Obviously, we cannot answer that by counting agents.
We need to understand their capabilities and authority.
That is the missing layer.
Welcome to the Agent Inventory Problem
Most organisations already have inventories for important technology assets.
They know—or at least try to know—their:
- Servers
- Applications
- Databases
- Cloud resources
- SaaS applications
- APIs
- Users
- Devices
- Security controls
But ask:
“Show me every AI agent in the organisation and tell me what each one can access.”
The answer may be surprisingly difficult.
Some agents will be formally approved.
Some will live inside development repositories.
Some will have been created as experiments.
Some will be embedded inside applications.
Some will be personal productivity tools.
Some will use third-party agent frameworks.
Some will be built by developers using open-source libraries.
Some may simply be a collection of prompts and tools that nobody has classified as an “agent.”
And some may have quietly acquired new capabilities over time.
This is not just an AI security problem.
It is an asset management problem.
The new question: Do you Know Your Agent?
We know concepts such as:
KYC — Know Your Customer
KYB — Know Your Business
KYT — Know Your Transaction
Perhaps the agentic era needs another one:
KYA — Know Your Agent
Before an organisation can govern an AI agent, it should be able to answer some basic questions.
Identity
What is this agent?
- Who created it?
- Which application owns it?
- Which team owns it?
- What framework does it use?
- Which model does it use?
Capability
What can it do?
- Can it execute code?
- Can it access files?
- Can it browse the internet?
- Can it query databases?
- Can it access GitHub?
- Can it send emails?
- Can it interact with cloud services?
- Can it call external APIs?
- Can it delegate to other agents?
Authority
What is it actually allowed to do?
An agent may declare one set of capabilities while its runtime identity, credentials or infrastructure grants another.
That difference matters enormously.
Behaviour
How autonomous is it?
- Does every action require approval?
- Can it make decisions independently?
- Can it create workflows?
- Can it invoke tools repeatedly?
- Can it delegate tasks?
Change
And perhaps most importantly:
What changed?
Because an agent that was safe last month may not be safe today.
KYA should become continuous
KYA shouldn’t mean filling out another spreadsheet once a year.
Agent environments change too quickly.
A useful KYA lifecycle could look like:
Discover
↓
Identify
↓
Understand capabilities
↓
Assess risks
↓
Establish baseline
↓
Monitor changes
↓
Reassess
↓
Govern
This starts to look remarkably similar to what happened with traditional software security.
We moved from:
“Do we have vulnerabilities?”
to:
“What changed in this pull request?”
Agent security needs a similar evolution.
Instead of asking only:
“Is this agent safe?”
we should increasingly ask:
“What new capability did this agent gain?”
Capability changes may matter more than code changes
Consider this pull request:
+ Added MCP server
+ Added browser tool
+ Added shell tool
From a traditional code-review perspective, this might not look particularly dramatic.
From an agent governance perspective, it could be enormous.
The agent has just moved from:
Read information
to:
Interact with the outside world.
That is a capability escalation.
The same principle applies when an agent gains:
- Database write access
- Cloud administration
- Email sending
- GitHub write access
- Shell execution
- New credentials
- Access to sensitive memory
- Delegation capability
This suggests a future where agent pull requests are reviewed not only as code diffs, but as capability diffs.
We are building the aircraft while inventing air traffic control
This is probably the uncomfortable part.
AI development is moving at extraordinary speed.
New models appear.
New frameworks appear.
New agent protocols appear.
New tools appear.
New MCP servers appear.
New agent patterns appear.
Developers can assemble increasingly powerful systems in hours.
The security and governance processes around them often move much more slowly.
That creates a dangerous asymmetry:
The cost of creating an agent is falling faster than the cost of understanding one.
And when the barrier to creation becomes extremely low, organisations can accumulate agents much faster than they accumulate governance.
We saw something similar with cloud infrastructure.
First came:
“Let’s put this in the cloud.”
Then:
“How many cloud resources do we have?”
Then:
“Who owns them?”
Then:
“Why does this production database have public access?”
Agentic AI may be heading toward the same cycle.
Only faster.
This is why visibility has to come first
Before organisations can answer:
“Is this agent safe?”
they need to answer:
“What is this agent?”
And before they can govern it, they need to understand:
“What can it do?”
That is the philosophy behind SafeAI.
SafeAI is an open-source static analyzer designed around a simple question:
What can this AI application actually do?
It examines an AI project without executing the agent or sending its data to an external service.
It looks for evidence across the project, including:
- Agent frameworks
- Tools
- Prompts
- Skills
- Workflows
- Model configurations
- MCP integrations
- Capability patterns
- Identity-related signals
- Memory and RAG
- External integrations
- Risk indicators
The objective isn’t to claim that static analysis can understand everything.
It can’t.
Dynamic behaviour, runtime permissions and infrastructure authority can introduce capabilities that source code alone cannot prove.
That’s precisely why the limitations matter.
A static scan can tell you:
“Here is what we can see.”
And just as importantly:
“Here is what we cannot verify.”
That distinction is essential for responsible AI governance.
Start building your Agent Portfolio
If your organisation is experimenting with AI agents today, you don’t need to wait for a perfect enterprise governance platform.
Start with something much simpler.
Find your agents.
Put them in one place.
Understand their capabilities.
Record their owners.
Identify their risky integrations.
Create a baseline.
Then ask what changed.
That’s your beginning of a KYA — Know Your Agent practice.
And it doesn’t need to start with hundreds of pages of governance documentation.
You can start with your repositories.
If you are a developer or security engineer, try running SafeAI against your AI projects.
It is free and open source:
github.com/ikaruscareer/SafeAI
Scan your agent projects.
See what SafeAI discovers.
Then tell us what it gets wrong.
Tell us what it misses.
Add a framework.
Add a capability.
Challenge the assumptions.
The project is deliberately open because no single team can keep up with the pace of the agent ecosystem alone.
The next generation of automation needs a new discipline
RPA taught us that software robots need governance.
Cloud taught us that infrastructure needs inventory.
Modern application security taught us that vulnerabilities should be found before production.
Agentic AI combines all three—and adds autonomy.
That creates a new challenge.
We are no longer simply deploying software.
We are increasingly deploying software that can decide what software actions to take.
That changes the governance equation.
The organisations that adapt early won’t necessarily be the ones with the most sophisticated AI governance platform.
They may simply be the ones that can answer basic questions first:
What agents do we have?
Who owns them?
What can they do?
What authority do they have?
What changed?
And what don’t we know?
That is the beginning of Know Your Agent.
And perhaps KYA will become to the agentic era what asset inventory became to cybersecurity:
not the whole solution—but the place where responsible governance begins.
The automation race has already started.
The question is no longer whether organisations will deploy AI agents.
They will.
The question is whether their understanding of those agents will grow as quickly as their capabilities.
Because the most dangerous agent in your organisation may not be the one with the worst intentions.
It may simply be the one nobody knows exists.
Know your agents before you have to discover them the hard way.
Start with your own agent portfolio
SafeAI is an open-source experiment in making AI agent capabilities visible through static analysis.
Scan. Discover. Challenge it. Contribute.
If you find something it misses, that isn’t necessarily a failure of the idea.
It may be the next capability the community needs to teach SafeAI to understand.
I particularly like this positioning for SafeAI because it doesn’t make KYA sound like a feature invented to sell a scanner. It presents KYA as a broader organisational discipline, with SafeAI as one practical OSS starting point.
For the eventual published version, I would also add a visual “Automation Evolution” timeline (RPA → GenAI → Agents → KYA) and a second visual showing “Agent capability explosion vs organisational visibility”. The latter could become the signature graphic for the article and SafeAI’s broader messaging.
Comments are closed