Why Traditional Security Cannot Govern AI Agents

The problem is not that security is obsolete

Traditional security is not obsolete. Enterprises still need identity and access management, network segmentation, endpoint security, data loss prevention, secrets management, secure software delivery, monitoring, incident response, and vendor assurance. Those disciplines remain the foundation for protecting systems that AI agents may touch. An AI agent with weak identity, excessive permissions, poor logging, insecure integrations, or vulnerable tools is a security problem before it is a governance problem.

The limitation is that security was built to answer a different class of question. Security asks whether a user, service, device, or workload is authenticated, authorised, protected, monitored, and resilient against compromise. Agent governance asks whether a delegated AI action is appropriate, accountable, within risk appetite, aligned with policy, subject to human oversight where needed, and evidenced well enough for later review. The two questions overlap, but they are not the same.

That distinction matters because AI agents do not only request access. They interpret objectives, choose steps, call tools, retrieve information, draft outputs, and sometimes affect records or workflows. A traditional security control may confirm that a tool call came from an authenticated service account. It may not know whether the tool call matched the human instruction, whether the agent exceeded its approved scope, whether the action needed approval, or whether the business owner accepted the residual risk.

Agents turn access into delegated action

The practical difference between ordinary software and an AI agent is delegation. A conventional application usually follows a designed path: a user clicks a button, the application validates input, and the system performs a known transaction. An AI agent may receive a goal, break it into steps, decide which tool to use, inspect data, produce intermediate reasoning, and take a sequence of actions. The enterprise may not know the exact path in advance.

This changes the control problem. Access control can say that an agent service may read tickets, query documents, open a pull request, send a message, or call an internal API. It does not automatically decide whether a particular combination of those actions is acceptable for a particular business purpose. A permission that is safe for one task can be unsafe in another. Reading an internal document may be acceptable for summarisation, but not for sending a customer response that contains sensitive material.

Delegated action also changes accountability. If an employee instructs an agent to prepare a customer email, and the agent retrieves the wrong record, drafts misleading text, and sends it through an approved integration, the enterprise needs more than a security log. It needs to know who initiated the action, what objective was provided, what data was used, what policy applied, whether review was required, who approved or overrode the output, and how the organisation responded after the issue was found.

Why identity is necessary but not enough

Identity is a starting point for agent governance. Without identity, the organisation cannot attribute actions to a person, service, agent, role, or team. Strong identity controls help prevent impersonation, overbroad access, weak service accounts, and unauthorised tool use. They also support accountability because a governed record needs to bind action to an actor.

The gap is that identity alone does not explain intent or appropriateness. A user may be allowed to access a customer record. An agent acting for that user may also be technically allowed to retrieve the record. The governance question is whether the retrieval was appropriate for the task, whether the record could be sent to a model provider, whether the output could be used externally, whether human review was needed, and whether the action stayed inside the approved use case.

This is why agent governance should bind identity to context. The record should not only show the user and service principal. It should show the agent, objective, workflow, data class, tool call, model or provider, policy decision, approval state, exception state, and outcome. Identity answers who. Governance answers whether the action should have happened under the circumstances.

Why data loss prevention is necessary but incomplete

Data loss prevention remains important for AI agents because prompts, retrieval, file uploads, generated summaries, tool outputs, embeddings, and logs can all move sensitive information. A DLP control may detect patterns such as payment data, credentials, health identifiers, customer records, or confidential terms. That capability is valuable and should be part of the control environment.

AI agents make data governance harder because the risk is not only exfiltration. Data can be transformed, inferred, summarised, combined, cached, embedded, or used to produce a downstream action. An agent may retrieve several low-sensitivity documents and combine them into a high-sensitivity operational picture. It may paraphrase sensitive information so a pattern detector misses it. It may call a tool that writes a generated output into another system where different access rules apply.

Governance therefore needs data rules that understand purpose and action. The enterprise should decide which data classes can be used with which models, providers, tools, workflows, and human review conditions. Some activity can be observed. Some can proceed with logging. Some should require approval. Some should be blocked or routed to a controlled environment. DLP detects important content patterns, but agent governance decides how data may be used in context.

Security logs do not equal governance evidence

Security logs are essential. They show authentication, API calls, network events, endpoint activity, data access, administrative changes, and alerts. They support investigation and incident response. But security logs are rarely designed to show the complete governance story for an AI agent action. They may show what system was called, but not what objective the agent was pursuing or why a policy allowed the action.

Agent governance evidence needs a different shape. It should connect the business purpose, agent identity, user identity, data class, model provider, prompt or instruction category, tool call, policy decision, approval requirement, human decision, exception, and final action. It should also show whether the use case was approved, which conditions applied, and whether the action triggered monitoring or remediation. This is the record that risk, compliance, legal, privacy, security, audit, and business owners can review together.

The difference becomes obvious during an incident. A security log may show that an agent called a messaging API at 10:42. A governance record should show that the agent was acting under a customer support workflow, used a particular knowledge source, attempted to include restricted data, triggered a policy decision, required approval, and was either approved, edited, blocked, or escalated. That context turns an event into an accountable decision trail.

Runtime context matters more than static permission

Traditional access control often relies on static permissions. A role can access an application. A service account can call an API. A user belongs to a group. That model is still necessary, but AI agents create actions whose risk changes with context. The same permission may be low risk or high risk depending on the task, data, output audience, autonomy level, and reversibility of the action.

Consider an agent that can draft support responses. Drafting a response based on public product documentation may be low risk. Drafting a response using a customer contract, a security incident note, or a legal dispute record may require review. Sending the response automatically is riskier than preparing a draft. Translating a response for a vulnerable customer may require additional quality review. The permission to draft text is not enough to govern the workflow.

An AI control plane evaluates the action when the action is attempted. It can ask whether the use case is approved, whether the user is allowed to delegate this task, whether the data class is permitted, whether the provider is approved, whether the tool call is inside scope, whether the action is reversible, and whether a human approval is required. That decision, made during operational use, is where governance moves from policy document to operating control.

Prompt injection shows the difference between security and governance

OWASP identifies prompt injection as a leading risk for large language model applications, ranking it first as LLM01:2025 Prompt Injection in its Top 10 for LLM Applications. Prompt injection matters for security because an attacker or untrusted content may manipulate a model into ignoring instructions, revealing information, or calling tools in unsafe ways. Enterprises should treat this as a real application security concern and design defences around input handling, tool boundaries, output validation, and least privilege.

Prompt injection also exposes the governance gap. If an agent is manipulated into taking an action, the enterprise needs to know which authority the agent had, which tool it could call, which policy decision occurred, what data was exposed, whether the action required approval, and which owners were notified. Security may detect the attack pattern. Governance decides how much authority the agent had in the first place, which OWASP catalogues separately as LLM06:2025 Excessive Agency, and what evidence remains after the event.

A strong agent governance model assumes agents may encounter hostile, ambiguous, stale, or misleading content. It therefore limits tool authority, requires approval for material actions, constrains data movement, records context, and triggers incident review. The aim is not to claim that prompt injection disappears. The aim is to reduce the blast radius and make the event reviewable.

The enterprise needs decision rights, not only controls

Security controls can be implemented by security teams, platform teams, and engineering teams. Agent governance needs decision rights across the enterprise. Someone must decide which agent use cases are allowed, which are prohibited, which require review, which data classes are restricted, which actions require approval, who can accept residual risk, and who can pause or disable an agent after an incident.

Those decisions usually cross functions. Security understands technical control design. Privacy understands personal information obligations. Legal and compliance understand regulatory exposure. Risk understands appetite and residual risk. Business owners understand the workflow and affected users. Internal audit understands whether evidence can be tested. AI agent governance fails when these perspectives are present in meetings but absent from enforceable decisions.

A useful operating model assigns owners. The business owner owns the outcome. The technical owner owns implementation and lifecycle operation. Security and privacy own control requirements in their domains. Risk and compliance own policy interpretation and residual-risk escalation. Internal audit tests the control environment independently. The agent governance system should make these roles visible in the evidence record.

Why a security-first view can understate business risk

Security teams are often first to see AI agent risk because agents interact with systems, data, identities, and APIs. That visibility is useful, but a security-first view can understate risks that are not primarily attacks. AI agents can create poor customer outcomes, inaccurate records, weak explanations, unfair prioritisation, contractual exposure, procurement risk, brand damage, and audit gaps without any attacker being present.

For example, an agent may summarise a customer complaint incorrectly and route it to the wrong queue. It may draft a policy explanation that omits an important exception. It may rely on a vendor feature whose model changed without review. It may create a ticket that triggers downstream work on the wrong account. These are governance and operational risks even when authentication, encryption, network controls, and endpoint security all worked correctly.

This is why boards and executives should avoid treating AI agent risk as a narrow cybersecurity topic. Cybersecurity is a major part of the answer, but not the whole answer. AI agent governance should sit across enterprise risk, operational resilience, privacy, legal, compliance, procurement, security, technology, and business ownership. The risk is created by the workflow, not only by the infrastructure.

Common failure patterns in agent governance

The first failure pattern is tool-by-tool approval. A team approves one chatbot, one code assistant, one workflow bot, or one vendor feature, then treats the review as complete. Agents do not stay neatly inside tool boundaries. They connect to documents, tickets, APIs, identity stores, messaging systems, repositories, and data platforms. A tool-level approval can miss the sequence of actions that creates risk.

The second failure pattern is treating an agent as a normal service account. A service account is usually assigned a known technical function. An agent may interpret goals, decide which function to use, and produce outputs that influence people. Giving the agent a service account without governing delegated authority creates a mismatch. The permission may be technically valid, while the action is outside the approved business purpose.

The third failure pattern is evidence after the fact. Teams launch an agent, collect a few logs, and assume they can reconstruct governance if something goes wrong. In practice, investigations need more than raw logs. They need intent, policy, owner, approval, exception, data class, model choice, and final outcome. If that record is not designed before deployment, it is usually incomplete when pressure arrives.

Why tool-by-tool review does not scale

Enterprises often begin AI governance with a review list. Which tools are approved? Which model providers are allowed? Which SaaS features are disabled? This is a useful first step. It gives teams a clear starting point and can reduce obvious unmanaged exposure. But it does not scale to agentic systems because agents create workflows across tools, not only usage inside a tool.

A single agent may use a search tool, a document store, a ticketing system, a code repository, a messaging application, and an internal API in one task. Each tool may be approved separately. The combined workflow may still be inappropriate because the agent can move information across boundaries or trigger downstream action. Tool review answers whether the component is acceptable. Agent governance answers whether the workflow is acceptable.

This is why the unit of governance should be the use case and action chain. The enterprise should review what the agent is trying to accomplish, which systems it touches, what data it processes, what outputs it creates, what humans review, and what evidence remains. Tool approval is part of that record, but it is not the record itself.

Assurance needs a testable agent record

Internal audit and assurance teams cannot test agent governance through aspiration. They need a record that links policy to operation. A testable agent record should show that the use case was approved, that the agent operated inside its defined scope, that high-impact actions required review, that exceptions were time bound, that incidents were recorded, and that material changes triggered reassessment.

This record also helps second-line functions. Risk teams can compare residual exposure across use cases. Privacy teams can inspect data movement and provider choices. Legal and compliance teams can examine whether controls support relevant obligations. Security teams can connect technical events to governance decisions. Business owners can see whether the agent supported the intended workflow or drifted into adjacent activity.

Assurance should test both design and operation. Design testing asks whether the controls are appropriate for the agent use case. Operating testing asks whether those controls worked during the review period. Did the approval happen before deployment? Did the policy decision occur at action time? Were blocked actions retained? Were human approvals visible? Were model, data, vendor, or permission changes reviewed? These questions require evidence, not confidence.

Implementation path for security and governance teams

A practical implementation path starts with the controls security teams already know. Establish strong identity, least privilege, approved integrations, secure secrets management, logging, monitoring, vendor review, and incident response. These controls reduce the chance that an agent is compromised or misconfigured. They also create the technical foundation that governance needs.

The next step is to add governance context. Each material agent should have an owner, approved purpose, risk classification, data-class policy, tool boundary, approval rule, exception process, monitoring plan, incident criteria, and evidence requirement. These fields do not need to become a heavy form for every low-risk experiment. They do need to exist for agents that can touch sensitive data, customer outcomes, regulated workflows, or operational systems.

The final step is to operationalise policy during operational use. If an agent attempts to use restricted data, call a high-impact tool, send an external message, change a record, or act outside the approved use case, the governance system should evaluate that action immediately. The response can be observe, alert, require approval, block, contain, or route for review. This is where security and governance become one operating discipline rather than two disconnected reviews.

What executive reporting should show

Executive reporting for AI agents should not be a list of model names or isolated security alerts. Leaders need to see where delegated AI action exists, which business processes depend on it, which systems agents can reach, which data classes are involved, and which decisions remain unresolved. That view allows management to compare AI exposure across functions instead of treating every agent as a separate technical experiment.

Good reporting also distinguishes volume from risk. A team may generate thousands of low-risk drafting assists with little concern, while a small number of autonomous record changes, external communications, or regulated decisions deserve close review. Reporting should therefore show use cases by risk tier, actions by intervention type, open exceptions, approvals, policy blocks, incidents, material changes, and overdue reviews. These measures help leaders ask whether governance is operating, not merely whether a project completed a review form.

The most useful board-level story is accountability. Who owns the agent? Who accepted residual risk? Which policies were tested in operation? Which exceptions are temporary? Which incidents changed the control design? Which areas still lack evidence? Traditional security dashboards can contribute signals, but they rarely answer those governance questions by themselves. Agent governance turns technical activity into a management record that can be questioned, improved, and tested over time.

A practical governance model for AI agents

A practical governance model starts with inventory. The organisation should know which agents exist, which users or teams can use them, which systems they can reach, which tools they can call, which data they process, and which business process they support. This inventory should include formal projects, vendor-embedded agents, internal automations, copilots, browser-based tools, and agent capabilities inside existing platforms.

The second layer is classification. Each agent use case should be classified by purpose, data sensitivity, external impact, autonomy, tool authority, reversibility, vendor dependency, and regulatory exposure. Low-risk drafting assistance should not receive the same process as an agent that can update records, send external communications, trigger payments, change access, deploy code, or affect customers. Proportionality keeps governance usable.

The third layer is operational control and evidence. Policies should be evaluated when agents act, not only when a project is approved. The control response should be graduated: observe, alert, require approval, block, contain, or route for review. Evidence should be retained in a structured record that links the action to the user, agent, objective, policy, approval, exception, and outcome. That is the layer traditional security alone does not provide.

Conclusion: Helixar perspective

Helixar’s view is that enterprises need a control-plane approach for AI agent governance. This framing emphasizes evaluating AI activity against approved purpose, delegated authority, data boundaries, and policy expectations; supporting proportionate governance responses; and retaining reviewable evidence. That matters because the governance problem is not only whether a model answered a prompt. It is whether a delegated action across tools, data, and systems stayed inside approved boundaries.

For security teams, the governance pattern can include approved-provider rules, sensitive-data restrictions, agent tool boundaries, policy decisions, review gates, and incident signals. For risk, compliance, privacy, legal, audit, and business teams, Helixar’s view is that organisations should preserve the context that ordinary technical logs often miss: objective, use case, policy, approval, exception, and evidence. The goal is a shared record that lets qualified owners review what happened without relying on scattered screenshots and meeting notes.

Helixar does not replace identity, DLP, SIEM, endpoint security, secure software delivery, or professional judgement. It complements those controls by adding the governance layer agents require: policy at the point of action, proportional intervention, human approval for material actions, and evidence that supports assurance. In practical terms, Helixar’s view is that enterprises can move from agent access to agent accountability.

Concretely, for the agent scenarios this piece describes, a support draft built on a customer contract, a tool call redirected by prompt-injected content, or several low-sensitivity retrievals combined into a high-sensitivity picture, the Helixar control plane sits in front of or in place of the AI gateway and evaluates each action at the moment it is attempted, across every model provider. At that point it verifies both the user and the agent identity and context, checks the action against the approved use case, data class, and delegated authority, and returns a graduated response of observe, alert, require approval, block, or contain, with fail-closed defaults and organisation-wide cost caps. Every one of those decisions, including the objective, policy outcome, approval or override, and exception, is written to a tamper-evident, independently verifiable evidence trail, which is the accountable decision trail the piece argues security logs cannot produce on their own. From that same record Helixar assembles framework-aligned evidence packs, with SOC 2 and ISO 27001 packs available today and ISO 42001, EU DORA, PCI DSS v4, APRA CPS 234, RBNZ BS-11, and the NZ Privacy Act 2020 mapped and delivered at implementation.

What leaders should ask next

Boards should ask whether management can name the agents operating in the enterprise and the systems they can reach. Which agents can read sensitive data? Which can write to business systems? Which can send external communications? Which can trigger irreversible or customer-impacting actions? Which are embedded in vendor platforms? Which have not been reviewed?

Executives should ask whether agent actions are governed during operational use. Are policies evaluated when agents act, or only when a project is approved? Which actions require human approval? Which data classes are prohibited or restricted? Which exceptions exist, who accepted them, and when do they expire? Can the organisation show evidence for a material agent action without reconstructing it manually?

Security, risk, compliance, legal, privacy, audit, and business owners should ask whether their control views connect. Can a security event be linked to a governance decision? Can a privacy concern be linked to data movement and provider choice? Can an audit test connect policy to operating evidence? If these records are disconnected, the enterprise may be secure in fragments while still weakly governed as a whole.