AI Agents Are Becoming Infrastructure Participants. Are We Securing Them That Way?
0
0
By Ankita Kharya
A chatbot suggests. An agent acts.
That difference changes the security model. Once AI agents can call tools, query systems, generate code, trigger workflows, or move data, they become participants in the operating environment.
A wrong answer creates an information risk. A wrong action can affect systems, data, customers, or production workflows.
So the enterprise question is simple: are AI agents being secured as infrastructure participants, or are they still being treated like smarter chatbots?
Why AI Agents Change the Enterprise Security Model
For years, enterprise security followed a familiar model. People used applications. Applications connected to systems. Security teams protected the boundaries between them.
AI agents change that model. They can interpret a goal, choose tools, access files, query databases, interact with APIs, communicate with other systems, and initiate downstream actions.
That means intelligence has to be paired with controlled autonomy. An AI agent with broad permissions becomes a new kind of machine identity. It can act on behalf of humans, move data, trigger workflows, and create effects across the business.
Once an agent can act, it needs to be governed.
Secure agentic architecture – Image
Every AI Agent Needs a Clear Identity
AI identity – Image | Shutterstock
Every enterprise AI agent should have a clear and auditable identity.
Security teams should be able to answer:
- Which agent took this action?
- On whose behalf?
- Under what policy?
- Using which tool?
- Was the action approved, automated, escalated, or blocked?
Without identity, logs may show that an API was called or a workflow was triggered, but not why it happened, which agent initiated it, or whether the action followed policy.
Every production agent should have an identity record that defines its owner, purpose, approved tools, data boundaries, permission scope, and escalation path.
Enterprises should ask:
- What can this agent do?
- Who is this agent in our environment?
Without a stable identity model, permissions, and audit trails, accountability becomes harder to manage.
Agent Permissions Should Be Scoped by Risk
Once an agent has an identity, permissions come next.
Agents should only access the tools, data, and workflows needed for their purpose.
A support-ticket agent should not modify production settings. A code-drafting agent should not deploy automatically. A finance-data agent should not initiate payments without review.
Classify actions by risk: automate low-risk tasks, review medium-risk tasks, and require stronger controls for high-risk actions like deploying code, changing permissions, modifying production systems, or initiating payments.
The default question should be: What is the narrowest access this agent needs to complete its intended task safely?
Secure AI-agent action workflow – Image
OWASP’s Top 10 for Agentic Applications identifies risks such as tool misuse, privilege abuse, goal manipulation, unexpected code execution, memory poisoning, insecure inter-agent communication, and rogue agents. The common thread is clear: agentic systems are both reasoning systems and execution systems.
Security Teams Need Visibility Into Agent Behavior
Observability shows what an agent actually does. Teams need visibility into tool calls, data access, execution chains, blocked actions, escalations, and outcomes.
Traditional logs may miss the bigger picture. One task can involve reading a document, calling an API, retrieving data, generating code, and triggering a workflow. Each step may seem harmless alone, but the full sequence can reveal the real risk.
Security teams need to know:
- What systems does the agent usually access?
- Which tools does it invoke?
- What does it attempt when blocked?
- Is it staying within its intended purpose?
A useful agent log should show the user request, agent identity, tool invoked, data accessed, action attempted, policy decision, and final outcome.
If an agent can act, the enterprise should be able to reconstruct what happened.
Tool Access Is Where Agent Risk Becomes Real
For agentic applications, tools are where plans become actions. The agent’s risk depends on which tools it can access, what data those tools expose, and how tool use is controlled.
Every connected tool should be treated as part of the attack surface. Identity checks, tool authorization, risk scoring, data boundaries, and approval workflows should determine what the agent can do, especially for high-impact actions like changing configurations, accessing sensitive data, approving transactions, or deploying code.
The model may decide what it wants to do. The enterprise must decide what it is allowed to do.
Build the Control Plane Before Scaling Agent Autonomy
Organizations should address security before agentic systems are embedded in workflows.
For AI agents, secure by design means building the control plane before scaling autonomy. That control plane should include identity, least-privilege access, tool-level authorization, approval workflows, human override, rollback controls, runtime monitoring, audit trails, red-team testing, data boundary enforcement, and clear accountability.
This approach aligns with broader security and AI risk-management guidance, including CISA’s secure-by-design principles and NIST’s AI Risk Management Framework.
The practical lesson is simple: autonomy should be governed in proportion to risk.
An agent that drafts internal notes does not need the same controls as an agent that can change production code, access customer data, modify firewall rules, or approve financial transactions.
The goal is to match governance to potential impact.
AI-Generated Software Still Needs Security Review
Reviewing code security – Image | Shutterstock
AI agents increasingly help create software, not just operate it. AI-assisted development can speed up prototypes, scripts, workflows, and integrations, but some of that work may bypass traditional engineering, security, or architecture review.
That makes agents part of the software supply chain. They can generate code, suggest dependencies, configure integrations, and connect systems. ACM’s TechBrief on vibe coding raises related concerns around security, reliability, and long-term code quality.
AI-generated software still needs ownership, review, testing, secrets scanning, dependency validation, secure design review, and runtime monitoring. Speed should not remove accountability.
Enterprise Security Checklist for Agentic Applications
Before an agentic application moves into production, teams should be able to answer a few practical governance questions.
| Control Area | What to Validate | Ready? |
| Agent identity | Defined identity, owner, purpose, environment, and audit scope | ☐ |
| Least privilege | Access only to approved tools, data, and workflows | ☐ |
| Action classification | Clear distinction between low-, medium-, and high-risk actions | ☐ |
| Tool authorization | Tool calls mediated by a gateway, policy layer, or approval workflow | ☐ |
| Risk-based approval | High-impact actions require human review or escalation | ☐ |
| Runtime observability | Monitor tool calls, data access, execution chains, and blocked actions | ☐ |
| Data boundaries | Prevent access outside approved tenant, role, or workflow boundaries | ☐ |
| Prompt and context defense | Test against prompt injection, goal manipulation, and context poisoning | ☐ |
| Rollback and containment | Reverse, isolate, or stop unintended actions quickly | ☐ |
| Secure SDLC | AI-generated code is reviewed, tested, scanned, and owned | ☐ |
| Ongoing governance | Review usage and permissions. Restrict or retire risky agents | ☐ |
Securing Agents Without Slowing Adoption
AI agents will become more useful as they take on real work across tools, teams, and systems. But that usefulness comes from the same capability that creates risk: the ability to act.
The problem is not that enterprises are adopting agents. The problem is when agents gain access, permissions, and workflow responsibilities faster than teams can understand and control them.
A practical security model starts with the basics. Every agent should have a clear identity. Its access should be limited to what it needs. Its actions should be visible. Its tools should be governed. And when an action could affect production systems, sensitive data, customers, or financial activity, human review should be part of the process.
This approach does not slow AI adoption. It makes adoption safer and more durable.
The organizations that get this right will treat agents as operational participants with defined roles, permissions, controls, and accountability. Once AI agents can act, security is no longer only about protecting systems from human users. It is also about protecting systems from autonomous participants operating inside them.
References
- Association for Computing Machinery (2026). AI-Assisted Software Development, or Vibe Coding: Benefits and Risks of AI-Driven Software Development. https://dl.acm.org/doi/full/10.1145/3807518
- Cybersecurity and Infrastructure Security Agency (2023). Software Must Be Secure by Design, and Artificial Intelligence Is No Exception. https://www.cisa.gov/news-events/news/software-must-be-secure-design-and-artificial-intelligence-no-exception
- National Institute of Standards and Technology (2023). AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework
OWASP GenAI Security Project (2026).OWASP Top 10 for Agentic Applications for 2026. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
Artificial Intelligence – The Data Scientist