As enterprise AI shifts from generating answers to taking actions, the security question changes with it. An AI agent may be able to call tools, access enterprise data, trigger transactions or hand tasks to other agents, creating governance problems that conventional identity and application controls were not designed to handle.
In this TNGlobal Q&A, Mohan Veloo, Chief Technology Officer for Asia Pacific, China and Japan at F5, shares insights about what enterprises should put in place before giving agents meaningful autonomy. He discusses task-specific permissions, MCP registries, chains of authority and why security controls need to operate while agents are acting, not only when models are selected or deployed.
What fundamentally changes about the security and governance model once an AI system is able to act rather than simply respond?
GenAI’s challenge was controlling what the system says. Agentic AI’s challenge is governing what the system does. A chatbot can give you a bad answer. An agent can send a payment, change a ledger entry, deploy an application, access sensitive information or instruct another agent. It can also do this at machine speed.
Governance therefore has to expand from reviewing the model to controlling the complete chain of action. Enterprises need to know who initiated the task, what authority was delegated to the agent, which tools and data it can access, what policies apply and where the action can be stopped.
These controls have to operate at runtime. Every request to a model, every tool call and every movement of sensitive data should be subject to policy as it happens.
What should a workable identity model for non-human actors look like?
Giving an agent a broad service account does not solve the identity problem. It recreates one of the worst habits of traditional IT in a far more autonomous environment.
An agent needs its own unique identity, a clear record of the person or system that delegated authority to it and a temporary credential limited to the specific task, tool, data and time required. An agent should never have more authority than the person or system it represents.
If one agent calls another, the identity of the original requester cannot disappear halfway through the workflow. That chain of authority must remain visible. Credentials should be short-lived and revoked when the task ends. Identity must travel with the task.
How should enterprises decide which MCP servers, tools and integrations can be trusted?
MCP could become the USB port of enterprise AI. It is incredibly useful, but also a quick way to connect something you have not properly inspected.
Enterprises need an approved registry of MCP servers and tools. Approval should consider who created the server, who owns it, what permissions it requests, which data it handles, its dependencies and how updates are managed.
Trust must also be continuously verified. A trusted tool can become untrusted after an update or if a dependency is compromised.
Ownership should be shared. The platform team operates the registry. Security defines the controls. Data and application owners approve access to resources. The business owner remains accountable for the use case. If it is not registered, approved and observable, it should not be in production.
Should agent permissions become more temporary and task-specific?
For agents, least privilege cannot be a job description. It has to be a task instruction.
Access should be based on what the current task requires, not everything the agent is generally capable of doing. Permissions should be issued just in time, expire automatically and be checked again before every sensitive action.
Enterprises must also examine transitive access. An agent may not have direct access to a sensitive system, but one of its tools may. Access should expire with the task. An agent should not leave permanent privileges behind it.
What does a useful audit trail need to capture?
A conventional API log may not be enough. It may show that a request occurred, but not why it was allowed or whose authority was being exercised.
If you cannot trace the authority, you do not have accountability. You simply have activity logs.
The audit trail should capture the original requester, the objective, every agent involved, the models and tools used, the permissions granted, the data accessed, the actions taken and the policy that allowed or blocked each sensitive step.
We should not confuse this with storing a model’s private reasoning. What matters is the request, relevant content, applicable policy, approvals and outcome. The chain of authority is essential. The chain of thought is not an audit strategy.
Where should human approval remain mandatory?
The technology being capable of an action does not mean the enterprise is ready to delegate it.
Human approval should remain mandatory for actions that could jeopardize human safety, create material financial loss, change production systems, delete or disclose sensitive data, alter security policies, create legal commitments, affect employment or significantly impact customers.
Routine, low-risk actions can be automated within clear thresholds. Higher-risk or unusual actions should be escalated.
Human approval must also be meaningful. If someone receives so many requests that they simply click approve, the control has failed. Reviewers need enough context to understand the proposed action and its consequences. The more irreversible the consequence, the stronger the case for human approval.
Where should organizations place controls against prompt injection and compromised tools?
Authentication tells you who the agent is. It does not tell you whether the instruction it is following is safe.
An authenticated agent can still be manipulated by content in an email, document, website, database or tool response. The threat can therefore enter after the agent has crossed the traditional security boundary.
Controls need to sit between the agent and the resources it can reach. Every tool call should be authorized, inspected and logged. Sensitive data should be protected before it reaches a model. High-risk actions should be constrained by approved destinations, transaction limits and human approval rules.
This is where an AI gateway becomes an important independent enforcement point. Do not ask the model to be its own security control.
What practical governance steps should Asia-Pacific enterprises put in place before giving agents meaningful autonomy?
Asia Pacific is not one operating environment. Regulations, data residency requirements, infrastructure, talent and legacy systems vary widely.
We do not need a different governance model for every country, but we do need one governance model that can be enforced across very different local environments.
Before granting autonomy, organizations should know which agents are running, which models and tools they use, where data moves and who owns each use case. They need approved model and MCP registries, clear identity and delegation rules, human approval boundaries, runtime policy enforcement and complete auditability.
Agents should begin in a narrow, preferably read-only environment. They should be tested against prompt injection, compromised tools, excessive permissions and unexpected actions before their authority is expanded.
The common mistake is focusing on the model while ignoring what the agent can reach or do. Agents do not fix poor processes or excessive access. They automate them.
Editor’s note: This Q&A has been lightly edited for clarity and style. The responses remain those of the interviewee.
Share your perspective: TNGlobal welcomes contributed insights and expert commentary from across Asia’s technology and innovation ecosystem. Submit a contribution for editorial consideration, or explore more conversations in our TNGlobal Q&A and Interviews archive.
Beyond vanity metrics: why startups need a new approach to PR [Q&A]