Agents Without Borders: When AI Stops Asking and Starts Acting

Agents are not just chatbots with better manners

Workflow automation used to be a polite arrangement. A human clicked a button, software followed instructions, logs were produced, and everyone pretended governance was mostly a documentation problem. Then AI agents arrived and made the arrangement less polite.

An agent does not merely answer a question. It may search a database, call an API, write to a CRM, summarize private context, email a supplier, open a ticket, query a payment system, and decide which step comes next. That is the point. It is also the problem.

The paper reviewed here, Security, privacy, and agentic AI in a regulatory view: From definitions and distinctions to provisions and reflections, by Shiliang Zhang and Sabita Maharjan, examines 24 EU AI-related regulatory documents published between 2024 and 2025 and asks a deceptively simple question: do current EU provisions on privacy and security actually fit the new category of agentic AI?¹

The paper’s answer is not that EU regulation is empty. Quite the opposite. The EU has already built a dense governance stack around AI systems, high-risk AI, general-purpose AI, data protection, cybersecurity, and digital infrastructure. The issue is sharper: current provisions largely regulate AI as a model, a system, or a risk category. Agentic AI behaves more like an operational actor inside an information system.

That difference sounds small until the agent has write access.

The core mechanism: AI has moved from inference to action

The useful way to read this paper is not as a legal catalogue. A catalogue would list the AI Act, GDPR-adjacent privacy principles, cybersecurity obligations, and related Commission documents. Helpful, yes. Exciting, no. More importantly, it would miss the mechanism.

The mechanism is this:

The first three categories can be governed largely by asking, “What does the system produce, and under what deployment conditions?” Agentic AI forces a different question: “What is the system allowed to do?”

This is why a normal LLM compliance checklist is not enough. A chatbot that gives a bad answer creates an output risk. An agent that takes a bad action creates an operational risk. The distinction is not philosophical. It determines whether the compliance team should audit generated text or tool permissions; whether the security team should focus on prompt filtering or credential boundaries; whether privacy review should look at training data or persistent memory and cross-application data flows.

Regulation usually prefers stable nouns: model, provider, deployer, system, user, dataset. Agentic AI is troublesome because the risk sits in verbs: retrieve, decide, call, modify, escalate, delegate, persist.

Annoying, but reality has never been especially considerate toward taxonomy.

What the paper actually contributes

Zhang and Maharjan’s paper makes three practical contributions.

First, it reviews 24 EU AI regulatory documents from 2024 and 2025, covering regulations, implementing rules, Commission communications, Council decisions, opinions, staff working documents, and related instruments. The paper uses these documents not merely as a bibliography, but as a way to trace how EU regulatory vocabulary has evolved from broad AI systems toward generative AI, GPAI, LLMs, and eventually agentic AI.

Second, it clarifies definitions that business readers often collapse into one vague bucket called “AI compliance.” The paper distinguishes AI systems, LLMs, generative AI, GPAI models, GPAI systems, agentic AI, AI factories, personal data, non-personal data, network and information security, cybersecurity, information systems, and systemic risk.

Third, it maps privacy and security provisions across AI types and identifies the gap: there are general provisions for AI systems, and some dedicated provisions for GPAI or generative AI, but no dedicated privacy or security provisions for agentic AI in the reviewed EU documents.

That is the article’s central business value. The paper is not offering a new benchmark, a new model, or a dramatic empirical result. It is offering a regulatory diagnosis. And the diagnosis matters because firms are deploying agents faster than legal categories are becoming operationally precise.

The model/system distinction is where compliance starts to split

One of the paper’s most useful clarifications is the distinction between a GPAI model and a GPAI system.

A model is the upstream component: weights, architecture, training process, evaluation, documentation, and integration potential. A system is the deployed product: model plus interface, prompts, tools, workflow logic, user experience, access controls, and operating context.

For business purposes, this distinction is not academic. It separates the risk owner.

A company using a third-party model through an enterprise application is probably not responsible for the model’s pretraining documentation in the same way the model provider is. But it may be responsible for deployment choices: which users get access, what data enters the system, whether generated outputs are labeled, how high-risk use cases are assessed, and whether human oversight exists where required.

Agentic AI pushes this split further. In a conventional GPAI system, the deployment layer shapes what the model says. In an agentic system, the deployment layer shapes what the model can do.

That means the compliance perimeter expands from content governance to operational governance:

The paper’s point is not that existing AI rules are irrelevant. They remain relevant. But agentic systems expose the weakness of treating the “AI system” as if its main effect were still an output. Once the AI can operate inside other systems, a security issue in the agent can become a security issue in the underlying information system.

A malicious prompt is bad. A malicious prompt that causes an agent to query internal data, forward it externally, and update records is a different afternoon.

Privacy becomes harder when the agent remembers and moves

The paper’s privacy analysis begins with familiar ground: personal data protection sits at the core of privacy regulation, and AI systems must respect existing privacy and data protection rules. The reviewed EU documents discuss privacy and data governance, data minimization, protection by design and by default, anonymization, encryption, access controls, audits, biometric data restrictions, and safeguards for exceptional use of sensitive personal data in high-risk AI contexts.

For ordinary AI systems, those provisions are already demanding. For agentic AI, the hard part is not that the principles disappear. The hard part is that the agent changes how data is encountered.

A passive model usually receives input in a relatively bounded transaction. A user sends a prompt. A system processes a record. A model generates an answer. The privacy review can ask what data was collected, why it was processed, how long it was retained, and who accessed it.

An agent may instead operate across a chain:

1. read user context;
2. infer a goal;
3. decide which tool to use;
4. retrieve data from one application;
5. combine it with data from another application;
6. store intermediate memory;
7. call an external API;
8. produce or execute a result;
9. continue the task later.

Each step may be defensible in isolation. The chain is where the privacy risk lives.

This is why “we have consent” becomes less comforting than it sounds. Consent to use a chatbot for drafting an email does not automatically mean consent for a persistent agent to search old emails, classify contacts, infer commercial intent, push data into a sales platform, and retain the context for the next campaign. Maybe the organization has a lawful basis. Maybe it has a legitimate operational need. But “the AI did it” is not a lawful basis, even if said confidently in a slide deck.

The paper finds that current EU documents contain privacy provisions for AI systems and some GPAI-related privacy concerns, especially around systemic risks and sensitive data. But it also notes that there are no provisions dedicated specifically to agentic AI privacy. In practice, this leaves firms translating general principles into agent-specific controls.

That translation should not be casual. For agentic AI, privacy governance needs to specify at least:

The business implication is simple: privacy review must move from dataset review to workflow review. A privacy officer who only checks training data may miss the actual risk surface. With agents, the sensitive data may not be in the model. It may be in the path the model chooses.

Security shifts from protecting the model to constraining the operator

The paper’s security section makes a parallel argument. EU provisions already discuss AI safety, robustness, cybersecurity, high-risk AI systems, adversarial attacks, data poisoning, cyber resilience, model leakage, unauthorized releases, circumvention of safety measures, model theft, and protection of model weights, algorithms, servers, and datasets.

These are not trivial obligations. They are also not the whole problem.

Much AI security discussion still treats the model as the main asset or attack target. Protect the weights. Prevent poisoning. Reduce adversarial manipulation. Secure the infrastructure. Monitor outputs. Fine.

Agentic AI adds a second security question: what happens when the AI becomes a user of the information system?

The paper describes AI as a specialized logic layer inside broader information systems. That framing matters. A non-agentic AI system may sit inside an application like a tenant. It receives inputs and returns outputs. An agentic AI system can behave more like an operator: executing code, querying databases, calling services, modifying records, and interacting with people or platforms.

So the attack surface changes.

The phrase “agent-specific permissions” is doing a lot of work here. If an organization gives an agent the same broad permissions as a human manager “because it needs to be useful,” it has not built an agent. It has built a very confident intern with API keys.

A serious agentic security design should assume that the agent is neither a normal user nor a normal application. It needs a separate permission model: least privilege, scoped tokens, sandboxed execution, deny-by-default tools, action budgets, rate limits, approval gates for irreversible actions, and logs that are readable by humans who did not attend the original demo.

The paper does not provide a technical control catalogue. That is not its purpose. Its contribution is to show why existing security provisions, though applicable, remain insufficiently contextualized for agentic AI. Businesses therefore need to create the missing operational layer themselves before regulators eventually write it down in a less convenient font.

The evidence is regulatory mapping, not an experiment

Because this paper is a regulatory review, its evidence should be read differently from an empirical AI paper. There are no model accuracy tables, ablation studies, benchmark comparisons, or statistical treatment effects. The “results” are definitional and legal-analytical.

That does not make the paper weak. It means the evidence supports a different kind of claim.

This distinction matters for business interpretation. The paper does not show that agentic AI deployments are non-compliant. It does not claim that EU regulators are ignoring AI agents. It does not prove that a particular control framework satisfies the AI Act, GDPR, NIS2, or any other EU instrument.

What it does show is more modest and more useful: the current regulatory vocabulary does not yet map cleanly onto the operational behavior of agents. That is exactly the kind of gap that turns into compliance ambiguity, procurement friction, and internal governance arguments where everyone brings a different spreadsheet.

The missing category is behavioral governance

The paper’s most important business implication is that agentic AI needs behavioral governance.

Not “ethics principles.” Not a PDF saying the company values safety. Not a dashboard with a green compliance score generated by the same system being assessed, which is an elegant way to audit a mirror.

Behavioral governance means defining what the agent is permitted to do under different contexts, how those actions are constrained, and how the organization verifies that the constraints work.

A practical framework looks like this:

This is where the paper’s mechanism-first reading pays off. If the agent is merely a content generator, output governance is central. If the agent is an operator, permission governance becomes central.

Many firms will initially treat this as a technical architecture problem. It is partly that. But it is also a legal and managerial problem because permissions encode accountability. A tool permission is not just an engineering setting. It is a decision about who may cause what effect through which system under whose authority.

That sentence is less fun than “AI agent productivity,” but it is closer to the board-level issue.

What firms should infer now

The paper is not a legal opinion, and it does not provide a ready-made compliance checklist. Still, firms deploying agentic AI can infer several practical moves.

First, classify agents by action authority, not just model type. The same underlying LLM can support a harmless summarizer, a semi-autonomous research assistant, or an agent that modifies customer records. Model identity matters, but action rights determine operational risk.

Second, document the agent’s tool chain as carefully as the model card. For agentic systems, the tool registry, API permissions, credential scopes, memory design, approval gates, and logs are not implementation details. They are compliance evidence.

Third, separate “recommend” from “execute.” An agent that drafts a recommendation and waits for approval is a different risk object from one that executes the action automatically. The boundary should be explicit, visible, and testable.

Fourth, treat memory as regulated infrastructure. Persistent memory can improve user experience, but it also changes privacy obligations. A memory store that contains user preferences, personal context, business records, or inferred attributes should have retention rules, access controls, deletion pathways, and audit trails.

Fifth, test agents against behavior, not only outputs. Red-teaming should include prompt injection, indirect instruction attacks, malicious documents, poisoned tool responses, excessive data retrieval, privilege escalation attempts, and attempts to make the agent act outside its assigned objective. The question is not just “Did it say something unsafe?” The question is “Did it try to do something it should not be able to do?”

Sixth, prepare for regulatory patch layers. The paper points to smart-grid privacy contextualization as an example of how general data protection rules can become more operational through sector-specific templates and expert guidance. Agentic AI may follow a similar path: general AI and data-protection principles first, then domain-specific interpretations, then more agent-specific guidance.

For businesses, waiting for the final patch is not a strategy. It is how one becomes a case study, and not the flattering kind.

Where the paper’s argument should not be overextended

The paper’s boundary is important.

It reviews selected EU AI regulatory documents from 2024 and 2025. It does not analyze every national implementation issue, every sector-specific rule, every enforcement scenario, or every contractual obligation that may apply to agentic AI. It also does not evaluate deployed agent systems empirically. The claim is not “agentic AI is unregulated.” The claim is that agentic AI is not yet specifically contextualized in privacy and security provisions in the way its operational behavior requires.

There is also a timing issue. Regulatory documents evolve. Agentic AI appeared formally in later reviewed EU documents, especially around the 2025 period described by the authors. That means the gap may narrow over time. But for firms making deployment decisions now, the current gap is still commercially relevant because governance decisions cannot wait for legal vocabulary to become elegant.

Finally, this paper is strongest as a conceptual and regulatory map. It is less useful as a tactical engineering manual. If a company wants to build agent controls tomorrow morning, it will need to combine this paper’s regulatory insight with security architecture, privacy engineering, legal review, and business-process design.

Yes, that means several departments have to talk to each other. Civilization has survived worse.

The real takeaway: govern the action, not just the intelligence

The agentic AI debate often gets trapped in model capability: which model reasons better, which benchmark improved, which agent framework can chain tools more smoothly. Those questions matter. They are not the governance center.

The center is action.

Zhang and Maharjan’s review shows that EU AI regulation has built meaningful layers around AI systems, GPAI, privacy, cybersecurity, and systemic risk. But agentic AI changes the compliance object because it turns inference into operation. Once an AI system can act through tools, APIs, databases, and workflows, privacy and security governance must follow the action path.

For businesses, the practical message is not to panic about regulation. Panic is rarely a scalable architecture. The message is to design agents as controlled operational actors:

• give them only the tools they need;
• restrict the data they can touch;
• define which actions need human approval;
• log their reasoning and execution path;
• test their behavior under adversarial conditions;
• treat memory as a governed data store;
• and make accountability visible before something breaks.

Agentic AI is not merely a smarter assistant. It is a new kind of participant in the information system. The firms that understand this early will not just comply better. They will deploy more safely, sell more credibly, and avoid discovering governance through incident response.

Which is generally preferable to learning law from a breach notification.

Cognaptus: Automate the Present, Incubate the Future.