Summary

• AI agents create a different enterprise risk profile because they can act across systems, not merely generate content.
• A new market is forming around agent visibility, governance, runtime controls, and enterprise security.
• Existing security disciplines still matter, but they need to be rebuilt around delegation, autonomy, tool use, identity, memory, and auditability.

The security problem with AI agents is not that they talk. It is that they act.

As companies move from chatbots and copilots into systems that can plan tasks, call tools, retrieve information, update records, and trigger workflows, the risk profile of enterprise AI changes. A system that only drafts text can still create legal, operational, and reputational problems, but an agent with access to live business systems can turn a poor instruction, weak permission, or malicious input into an action that has to be traced, contained, and sometimes reversed.

That shift is beginning to reshape the enterprise AI market. London-based Geordie AI has raised $30 million in Series A funding led by Balderton, taking total funding to $36.5 million. The company describes its product as a security and governance platform for AI agents, built to help enterprises understand which agents exist, what they can access, how they behave, and what risks they create across business systems.

One funding round does not establish a market on its own, but it does show where enterprise anxiety is concentrating. Agent visibility, runtime controls, governance, remediation, and auditability are becoming distinct buying concerns because agentic AI sits between automation, security, compliance, and workflow software. The question is not only which model an organisation uses, but what authority that model-connected system is allowed to exercise.

Early AI policies were built for a different risk

Many organisations began their AI governance work with policies covering acceptable use, data handling, prompt hygiene, approved vendors, and model selection. Those controls remain necessary, although they were designed mainly for systems that help people produce, summarise, or interpret information. Agents introduce delegated authority, which means security teams must understand not only what the system knows or generates, but what it can do inside the organisation.

Visibility is the first operational weakness. Security teams cannot govern agents they cannot see, and sanctioned deployments are only part of the picture. Some agents will arrive through enterprise platforms procured centrally, while others will appear through departmental experiments, workflow automation tools, low-code environments, developer projects, or employee-built shortcuts. The result resembles shadow IT, but the risk is sharper because these systems may hold credentials, access internal data, and execute tasks across multiple applications.

Inventory then has to become more detailed than a list of tools. Organisations need to understand which identity each agent uses, which systems it can access, which actions it can initiate, whether it can communicate externally, what data it can retain, and which person or team owns its behaviour. Conventional access-control models assume a relatively stable relationship between a user, an application, and a permission set; agents complicate that model because they may operate on behalf of a person, a team, a business process, or another automated system.

The attack surface is widening

The security community is already mapping how agentic systems alter application risk. The OWASP GenAI Security Project says generative and agentic AI are changing how applications are built, deployed, and operated, while expanding the attack surface in ways traditional application security programmes were not designed to handle. Its Top 10 for Agentic Applications focuses on systems that can plan, act, use tools, and make decisions across workflows, which makes the security problem broader than prompt quality or model choice.

Academic security research points in the same direction. A 2026 systematic survey of LLM-based AI agents describes a security surface that differs from stateless language models because agents can persist memory, invoke external tools, coordinate with other agents, and operate across sessions. Attacks can emerge through prompts, but they can also exploit architectural state, delegated authority, and long-horizon interaction.

Prompt injection becomes more serious once prompts can influence action. A malicious instruction hidden in a document, webpage, email, ticket, or knowledge-base entry may steer an agent that retrieves information and then acts on it. Tool misuse becomes a design problem when agents can call APIs or trigger workflow steps without enough context. Memory poisoning becomes a governance problem when corrupted or manipulated information persists across sessions. Multi-agent systems add further complexity if one system’s output becomes another system’s instruction.

Old controls need new assumptions

Security teams do not need to abandon established disciplines, but those disciplines need to be adapted around autonomy, delegation, and machine-speed action. Least privilege still applies, although it becomes harder to define when an agent may need temporary access to several systems to complete a task. Logging remains essential, but the log has to explain not only what action occurred, but which prompt, tool call, data source, permission, and approval path led to it.

Human approval also needs careful design. Keeping a person in the loop can reduce risk for high-impact decisions, yet approval prompts that arrive too often, contain too little context, or interrupt work at the wrong moment can become rubber stamps. Sandboxing can limit exposure during testing, but agents intended to work across live business systems cannot remain permanently inside a controlled environment. The control model has to fit the workflow rather than sit beside it as a theoretical safeguard.

The market around those controls is likely to be contested because agent security cuts across several existing categories. Identity providers will argue that agents need managed identities and scoped privileges; cloud security vendors will treat them as workloads; observability companies will extend monitoring into AI workflows; governance, risk, and compliance platforms will add AI inventories and audit trails; enterprise AI platforms will build native guardrails. Specialist vendors will press the case that agents require purpose-built runtime controls because ordinary application security was not designed for systems that reason, use tools, and take actions across business processes.

Several of those claims can be true at the same time. The more likely outcome is a security layer spread across identity, AI operations, cloud, compliance, observability, and enterprise software rather than a single clean category. Buyers will need to avoid treating agents as ordinary software with a conversational interface, while also resisting the idea that novelty excuses weak access control, poor logging, unclear ownership, or vague incident response.

Security has to follow the action

A workable model begins with authority. An agent should not have more access than the task requires, and every meaningful action should be attributable, constrained, logged, and reversible where the workflow allows it. That requires agent inventories, scoped credentials, approval thresholds, runtime monitoring, secure tool interfaces, adversarial testing, ownership models, and incident playbooks designed for automated execution rather than only human error.

Governance will also need to sit closer to product and process design. A finance agent, a customer-service agent, an engineering agent, and a procurement agent do not carry the same risk simply because they use similar underlying models. Each one operates inside a different workflow, touches different data, and creates different failure modes. Treating agent security as a central policy document detached from deployment context would reproduce the weakness of many early AI rules: a sensible standard on paper, with too little control where work actually happens.

AI agents may become ordinary parts of enterprise operations, but only if they are governed as actors inside systems rather than chat windows with extra permissions. Once software can act across business processes, security has to follow the action.