Logo Virtualtek
GET STARTED
Logo Virtualtek
Logo Virtualtek

"It Works While You Sleep."

What Your Agentic AI Is Actually Doing
Inside Your Infrastructure

Written by Arnaud Simonis, VMware L3 Engineering, Virtualtek CEO
Published July, 13 2026 | 9 min read

An AI agent connects to your inbox, your documents, your calendar.

It runs while you are in a meeting, while you are asleep, while you are not watching.

The productivity case is real.

What nobody maps before deployment — the data that leaves your infrastructure, the permissions that persist, the attack surface that grows with every tool connected — determines whether that agent works for you or against you.

Key Takeaways
  • Where the agent runs determines whether your data stays inside your infrastructure — this decision precedes everything else and cannot be corrected after deployment
  • The model you choose is the data policy you accept: every cloud inference call triggers General Data Protection Regulation (GDPR) Article 28 obligations automatically, regardless of the provider's size or reputation
  • Without guardrails, an autonomous agent executes what it receives — including malicious instructions embedded in an email or a document it processes without human oversight
  • Every tool connected to the agent expands the attack surface — without sandboxing and least-privilege scoping, a single compromised input can reach everything the agent is authorized to touch
  • An agent's memory can be poisoned via an ingested document — corrupting its outputs silently, over time, without triggering any visible alert
  • Interface validation and model-level guardrails are not redundant — they are layered; removing either leaves a gap an attacker or a motivated user will find
  • Testing that the agent works is not testing that it is secure — functional validation and adversarial security testing require different methods and different expertise
  • A sandbox that replicates production conditions is required before any adversarial test can be meaningful — and before any production exposure can be justified
  • An agent in production without monitoring, client-side logging, and a defined update cycle is not governed — it is in an uncontrolled state that resembles production

Where Does Your Organization Stand?

Five profiles.

One question: who controls your agent?

ProfileWhat happenedWhat is actually runningBusiness exposure
01Found a free agent online and installed itA post, a link, a five-minute setup. The agent connected to the mailbox and started working.Unknown external APIs, unknown data processors, unknown retention policies. The agent appears to work. What it sends where is invisible.Maximum exposure — unauditable data flow — GDPR breach by default
02Clicked Authorize. The agent is running.A known provider, an official tool. Access granted to the mailbox and document repository during setup.OAuth token reaches the full account perimeter. No DPA confirmed. No service account. No audit trail on what the agent read and transmitted.Uncontrolled data exposure — Article 28 compliance failure — no incident reconstruction possible
03Deployed and tested the features.The agent was tested before go-live. It did what it was asked. The team validated the outputs.No guardrails. No sandboxing. No adversarial testing. The agent works — until it receives an input it was not designed for.Functional validation without security validation — one malicious input away from an incident
04DPA signed. Service account in place.Legal coverage obtained. A dedicated account was created with scoped permissions. The agent is considered governed.Legal and access exposure partially addressed. No monitoring. No client-side audit log. No update procedure. Governance on paper, not in production.Partial control — operational governance gap — silent liability growing in production
05Agent architecture documented and governed.Architecture decision made before deployment. Environment, model, tools, guardrails, testing, monitoring — each layer addressed explicitly.Dedicated VM or controlled environment. Scoped service account. DPA confirmed. Guardrails active. Adversarial testing completed. Client-side audit log running. Update cycle defined.Defensible operations — full auditability — bounded blast radius — EU AI Act compliant

Each profile corresponds to a set of decisions — or the absence of them.

The nine sections that follow address each layer in the order it must be resolved, starting with the decision that determines all the others.

1. Runtime Environment: Where Your Agentic AI Actually Runs

The first question is not « what can this agent do? » It is « where does it run? »

A free agent found online connects to an external runtime the moment you authorize it. The language model processing your requests does not run on your machine — it runs on servers belonging to the agent’s creator, or to a third-party API provider that creator chose. Your emails, your documents, your internal notes leave your infrastructure with every inference call. You do not control where they go, how long they are stored, or what the provider’s data retention policy says.

This is not a configuration issue. It is an architecture decision — and it is made the moment you choose the agent, before you type a single prompt.

A self-hosted agent running inside a dedicated virtual machine on your own infrastructure is the only deployment model where data does not leave your network during inference. Everything else involves a data transit you need to map, classify, and legally cover before the agent processes its first task.

Runtime environment determines the data exposure baseline. LLM selection determines who is legally responsible for what happens to that data — and under which regulatory framework.

TECHNICAL REALITY

A free agent found online may call multiple external APIs during a single task: the Large Language Model (LLM) like Claude or ChatGPT provider for inference, a third-party memory service for context retrieval, an external logging endpoint, and analytics services embedded in the agent's code. None of these are visible in a five-minute setup flow. Auditing what a third-party agent actually calls requires reading its source code — or monitoring its outbound network traffic after deployment.

BUSINESS IMPACT

An organization that deployed a free agent without auditing its external calls has no visibility into what data left its infrastructure, when, and to which endpoints. If a regulatory audit or a data breach investigation follows, reconstructing that data flow from the outside is expensive, slow, and may be impossible.

The cost of auditing an agent before deployment is a fixed, bounded effort. The cost of reconstructing what an unaudited agent sent where — after an incident — is open-ended.

2. LLM Selection & GDPR Article 28: The Data Policy You Accept

Every inference sent to a cloud language model is a data transfer. The content you send — emails, documents, internal notes — is processed on the model provider’s infrastructure. Under GDPR Article 28, the provider becomes your data processor the moment that processing begins. This classification is automatic. It does not require a declaration.

A Data Processing Agreement (DPA) must exist before the first token is processed. It must specify what data is processed, for what purpose, under what security measures, and for how long. If the provider’s servers are outside the European Union — which is the case for most major LLM providers — a legal transfer mechanism must cover that data flow: Standard Contractual Clauses, an adequacy decision, or Binding Corporate Rules.

An organization that installed a free agent connected to a cloud LLM and authorized access to its mailbox has created a data processor relationship with a provider it may never have heard of — with no DPA, no transfer mechanism, and no visibility into the provider’s retention policy.

TECHNICAL REALITY

A free agent typically does not use a single LLM provider. It may chain multiple models: one for reasoning, one for embeddings, one for summarization. Each is a separate data processor relationship under GDPR. Each requires its own DPA assessment. The agent's documentation — when it exists — rarely maps these dependencies explicitly.

BUSINESS IMPACT

Administrative fines under GDPR reach €20 million or 4% of global annual turnover, whichever is higher. The absence of a DPA with a data processor — regardless of whether a data breach occurred — is a standalone compliance failure. A supervisory authority audit triggered by any unrelated event will expose it.

No agent that processes personal data on behalf of your organization should run without a signed, Article 28-compliant DPA with every model provider in its processing chain.

LLM selection and GDPR Article 28 address the infrastructure and legal layer. AI agent guardrails address what happens once the agent starts reading content autonomously — and they apply regardless of deployment model.

3. AI Agent Guardrails: Why Content Validation Is a Prerequisite

An autonomous agent reads what it finds and acts on what it reads. Without a control layer between incoming content and the model, the agent has no mechanism to distinguish a legitimate instruction from a malicious one embedded in an email, a document, or a web page it was directed to fetch.

This is prompt injection — the primary attack vector specific to agentic AI, listed by OWASP as LLM01:2025. It requires no system credentials. It requires no access to your infrastructure. It requires only that a crafted message reaches the agent’s input queue. In an email-connected deployment, that means any inbound email.

Guardrails — input validation layers that filter content before it reaches the model, and output validation layers that check what the model produces before it acts — are the technical response to this exposure. They are not optional. An agent without guardrails that processes untrusted content is not a governed agent. It is an open execution environment. This applies equally to a cloud-hosted agent and to a self-hosted one.

TECHNICAL REALITY

A prompt injection attack does not require the attacker to access your systems. A crafted email landing in the connected inbox is sufficient. The agent reads the email as part of its task, encounters the embedded instruction, and may execute it — forwarding a document synthesis to an external address, modifying the output of the next task, or triggering an action in a connected tool. Traditional perimeter security does not block this vector. It travels inside legitimate email traffic.

BUSINESS IMPACT

An agent connected to executive communications and internal document storage, operating without guardrails, is a meaningful target. The blast radius of a successful prompt injection depends entirely on what tools the agent can reach — which is why guardrails and tool scoping must be addressed together, before deployment.

A single successful prompt injection against an ungoverned agent with broad tool access can exfiltrate an entire document repository. Remediation costs — forensics, regulatory response, notification — routinely exceed the full cost of a properly governed deployment.

AI agent guardrails control what the agent reads and what it produces. Tool scoping controls what it can do — and how far a breach travels if guardrails are bypassed.

4. Tool Scoping: Why Every Connected Integration Is an Attack Surface

An agent’s value comes from what it can act on — email, documents, calendars, business tools. Every connection you authorize expands what the agent can reach. Without sandboxing and explicit least-privilege scoping at the tool level, every connection also expands what an attacker can reach through the agent.

An agent connected to a mailbox, a document repository, and a code execution environment — without isolation between those layers — is a single attack surface. A successful prompt injection, or a compromised tool response, can reach everything the agent is authorized to touch. The blast radius is not determined by the attack. It is determined by the tool architecture you built before deployment.

Each tool connection must be scoped to what the agent’s tasks strictly require: read access to a specific folder, not the full mailbox; execution rights inside a sandboxed container, not on the host system. Code execution is the highest-risk capability an agent can hold — without a dedicated isolated environment with network restrictions and no write access outside a defined temporary directory, it is a privilege escalation vector.

TECHNICAL REALITY

A free agent that requests broad permissions during setup — full mailbox access, full file system access, code execution — is not requesting what it needs. It is requesting what it can get. Default permission grants during setup are rarely reviewed against actual task requirements. Once granted, those permissions persist until explicitly revoked.

BUSINESS IMPACT

An agent with code execution capability and broad file system access, running without sandboxing, is the highest-risk configuration in an enterprise environment. If compromised via prompt injection, it can read, write, exfiltrate, or destroy data across the perimeter it was granted. The human-in-the-loop checkpoint for any irreversible action is not a convenience feature — it is the boundary between a recoverable incident and an unrecoverable one.

Every irreversible action an agent can trigger — sending, writing, deleting, executing — must require explicit human approval. Removing that checkpoint in the name of full autonomy removes the last line of defense against a compromised agent.

Tool scoping limits what the agent can act on. RAG memory poisoning operates at a different layer — it corrupts what the agent trusts as context before it acts.

5. RAG Memory Poisoning: The Silent Attack Vector

When an agent is equipped with a memory layer — a local vector database storing documents, past interactions, and retrieved context — it trusts that memory as a source of truth. It does not verify the origin or integrity of what it retrieves. It reads it and reasons on it.

This creates an attack vector called indirect prompt injection: an attacker embeds malicious instructions inside a document that the agent ingests into its memory. The document could be a contract, a shared report, a supplier invoice. Once indexed, the embedded instruction persists in the agent’s context and may be retrieved and executed in a future task — potentially weeks after the document was ingested, with no visible trigger.

Unlike a direct prompt injection via email, memory poisoning is silent and persistent. The agent’s outputs are corrupted over time, based on context the organization considers trusted. Detection requires active monitoring of what the agent retrieves and how it reasons — not just what it produces.

TECHNICAL REALITY

Every document ingested into the agent's memory must be treated as potentially untrusted until validated. Content retrieved from third-party sources — supplier documents, client attachments, web pages — carries the highest risk. Input sanitization before indexing, source classification, and separation of trusted from untrusted content sources are not optional steps in a production memory architecture.

BUSINESS IMPACT

Memory poisoning is the hardest agent compromise to detect. It does not produce an immediate anomaly. It degrades output quality gradually, in ways that may be attributed to model drift or user error before the root cause is identified. By the time the corruption is detected, the agent may have produced and distributed flawed outputs across multiple workflows.

An agent whose memory is not actively monitored and whose input sources are not classified by trust level is not a governed agent — it is a system whose outputs cannot be fully trusted over time.

RAG memory integrity depends on what enters the agent’s context from external sources. Interface validation addresses the direct entry point — where users interact with the agent and where the most accessible attacks originate.

6. Interface Validation: The Entry Point Most Deployments Leave Open

The interface through which users interact with the agent — a chat UI, a web form, an API endpoint — is the entry point for direct prompt injection. Without input validation at this layer, every user input reaches the model unfiltered. A user who knows how the agent is configured can probe it, override its instructions, or extract information it was not meant to share.

This is not a theoretical risk. It is the most accessible attack vector for a non-technical attacker: no infrastructure access required, no specialized tooling. A carefully crafted message submitted through the interface is sufficient.

Input validation at the interface layer is distinct from guardrails at the model layer — both are required. The interface filters what reaches the guardrails. The guardrails filter what reaches the model. Removing either layer leaves the other exposed.

TECHNICAL REALITY

A free agent deployed with a default web interface typically has no input validation layer. The interface sends user input directly to the agent's orchestration layer. If the system prompt is weak or predictable, a user can override the agent's instructions, extract its configuration, or redirect its behavior — without any technical access to the underlying infrastructure.

BUSINESS IMPACT

An agent deployed internally without interface-level validation is exposed to every user who has access to it — including users whose intent may not be aligned with the organization's. For agents with access to sensitive data or action-taking capabilities, this is a material internal threat surface that most deployment guides do not address.

Interface validation and server-side guardrails are not redundant — they are layered. Deploying one without the other leaves a gap that a motivated user or attacker will find.

Interface validation and guardrails protect the agent during normal operation.

Adversarial security testing validates that those protections hold under deliberate attack — before production exposure.

7. Adversarial Security Testing: Why Functional Validation Is Not Enough

Testing that an agent produces correct outputs for expected inputs is functional validation. It confirms that the agent works. It says nothing about what the agent does when it receives inputs it was not designed for.

Security testing is a separate discipline. It requires deliberately constructing adversarial inputs — known injection patterns, edge cases, attempts to override system instructions, inputs designed to trigger unintended tool calls — and verifying that the agent’s guardrails block them. This is red teaming, and it requires the OWASP LLM Top 10 as a minimum reference framework.

An agent that has passed functional testing but not security testing has been used, not validated. The gap between the two is where incidents happen — not in production anomalies, but in the first adversarial input the agent encounters after go-live.

TECHNICAL REALITY

Security testing for an AI agent covers at minimum: prompt injection attempts across all input surfaces, system prompt extraction attempts, tool call manipulation, memory poisoning via test documents, output validation bypass attempts, and privilege escalation via chained tool calls. Each vector corresponds to a specific guardrail that must be validated as effective — not assumed to be working because it was configured.

BUSINESS IMPACT

The cost of a security testing cycle before production is fixed and bounded. The cost of a security incident after production — forensics, regulatory notification, remediation, potential fines, reputational damage — is open-ended. Organizations that skip security testing do not avoid that cost. They defer it to a moment when it is significantly higher.

A security test that finds nothing is not evidence that the agent is secure. It is evidence that the tests were not adversarial enough. Red teaming requires expertise in LLM attack patterns — not just familiarity with the agent's intended behavior.

Adversarial security testing validates the agent against known attack patterns.

The sandbox environment is the prerequisite that makes that testing meaningful — and safe to run.

8. Sandbox Environment: Isolated Testing Before Production Exposure

Security testing requires an environment that is isolated from production — a sandbox where adversarial inputs can be injected, tool calls can be triggered, and failure modes can be observed without affecting live data, live systems, or live users.

An agent tested directly on a production environment, with live mailbox access, live document repositories, and live tool connectivity, cannot be tested adversarially. The tests that matter — injection attempts, tool manipulation, privilege escalation chains — cannot be run safely without isolation.

The sandbox is also the environment where the agent’s behavior under unexpected conditions is characterized before those conditions occur in production. An agent that has never been exposed to edge cases in a controlled environment will encounter them for the first time in front of real users, with real data, and with no rollback path.

TECHNICAL REALITY

A proper sandbox for an AI agent replicates the production architecture — same model, same orchestration layer, same tool integrations — with isolated, non-production data and network-level restrictions that prevent outbound calls to production systems. It is not a simplified version of the agent. It is the full agent running against controlled inputs in a controlled environment.

BUSINESS IMPACT

Organizations that deploy directly to production without a sandbox phase accumulate a security debt that is invisible until an incident makes it visible. The sandbox phase is also where the organization discovers which guardrails need tuning, which tool permissions are misconfigured, and which edge cases the agent handles poorly — before those discoveries have operational consequences.

The cost of building and running a sandbox is a fraction of the cost of a production incident caused by an agent that was never tested under adversarial conditions. There is no shortcut that changes this ratio.

The sandbox validates the agent before production exposure. Once in production, a different set of disciplines takes over — production governance: monitoring, audit logs, and update cycles.

9. Production Governance: Monitoring, Audit Logs, and Update Cycles

An agent in production without monitoring is an agent whose behavior is unknown between the moment it acts and the moment an output is reviewed. That gap — between action and review — is where silent failures, gradual corruption, and undetected compromises accumulate.

Production governance requires three active disciplines. Monitoring: continuous observation of what the agent reads, what it retrieves from memory, what tools it calls, and what it produces — with alerts on anomalous patterns. Logging: a client-side audit trail of every task execution, with timestamps and data source references, accessible without relying on the provider’s infrastructure. Update procedures: a defined cycle for updating the model, the orchestration layer, the guardrails, and the tool integrations — because each component has its own vulnerability surface that evolves over time.

In a regulated environment, the absence of any of these three is not a configuration gap. It is a governance failure — and it is auditable independently of whether any incident has occurred. Virtualtek’s AI governance audits systematically map these three dimensions as a priority, because they are the most frequently missing in organizations that consider their agent deployment complete.

TECHNICAL REALITY

Client-side logging of agent activity must capture, at minimum: which account and data sources were accessed per task, which tools were called and with what parameters, what content was retrieved from memory, and what outputs were produced. This log must be stored on infrastructure the organization controls — not dependent on the AI provider's retention policy or cooperation in the event of an investigation.

BUSINESS IMPACT

A compliance audit, a data breach investigation, or a DPO review will require reconstruction of what the agent accessed and when. Without client-side logging, that reconstruction depends on the provider's logs — which may not be available, may not cover the relevant period, and may not be contractually accessible. In a regulated sector, this gap is itself a compliance finding, independent of the incident that triggered the audit.

An agent running in production without client-side logging, active monitoring, and a defined update cycle is not in production. It is in an uncontrolled state that resembles production.

Nine decisions.

Each one determines whether an incident is prevented, contained, or unrecoverable.

The table below maps where each of the five profiles stands across these nine layers.

The Nine Layers: Where Each Profile Stands

Layer01 Free agent installed02 Clicked Authorize03 Tested features04 DPA + service account05 Governed
1. Runtime EnvironmentUnknownCloud, unverifiedCloud, partialCloud, scopedVM dedicated or governed cloud
2. LLM / GDPR Art. 28No DPANo DPANo DPADPA confirmedDPA confirmed or no processor
3. AI Agent GuardrailsNoneNoneNonePartialActive — input + output
4. Tool ScopingUnknown / broadFull account perimeterFull account perimeterService account scopedLeast privilege — sandboxed execution
5. RAG Memory PoisoningUnknown sourcesUnvalidatedUnvalidatedPartial validationSanitized — source classification active
6. Interface ValidationNoneNoneNonePartialClient + server validation active
7. Adversarial TestingNoneNoneFunctional onlyFunctional onlyAdversarial — OWASP LLM Top 10
8. Sandbox EnvironmentNoneNoneNonePartialIsolated — production-equivalent
9. Production GovernanceNoneNoneNoneNoneMonitoring + logging + update cycle

Deploy Governed. Not Just Deployed.

Nine layers.

Each one a decision that either bounds your risk or leaves it open.

Virtualtek designs and deploys enterprise AI infrastructure with security and governance built in from the architecture layer — covering environment selection, model and legal coverage, guardrails, tool scoping, memory integrity, interface validation, security testing, sandbox design, and production governance.

As exclusive European distributor of the RAIGF™ — Responsible AI Governance Framework — Virtualtek provides the operational structure to move from a deployed agent to a governed one.

Book an AI & IT Governance Consultation

Frequently Asked Questions

Direct answers — no vendor bias, no marketing framing.

Not without auditing it first. A free agent may call multiple external APIs during a single task — for inference, memory, logging, analytics — none of which are visible during a five-minute setup. Before connecting a free agent to any business data source, its source code and outbound network traffic must be reviewed. The permissions it requests during setup are not necessarily what it needs — they are what it will use.

A self-hosted, open-source agent running inside a dedicated virtual machine on your own infrastructure. In this configuration, the language model runs locally — no inference call leaves your network. There is no external data processor, no Article 28 DPA required for the model itself, and no provider retention policy to verify. Data sovereignty is guaranteed by architecture, not by contract.

Yes, automatically. The moment a cloud-hosted agent processes personal data on behalf of your organization, the provider becomes a data processor under GDPR Article 28. A Data Processing Agreement must exist before that processing begins. If the provider's infrastructure is outside the EU, a legal transfer mechanism — Standard Contractual Clauses or equivalent — must cover the data flow. These obligations do not wait for the legal team to be notified.

Prompt injection embeds malicious instructions inside content the agent processes autonomously — an email, a document, a web page. The agent reads it and may execute the instruction without any authentication barrier. It applies to any autonomous agent, cloud-hosted or self-hosted, that processes untrusted content. The attack surface is determined by what the agent reads, not where it runs. Guardrails are required in both deployment models.

Code execution capability, without a dedicated sandboxed container with network isolation and strict file system restrictions, gives an agent — or an attacker controlling it via prompt injection — the ability to read, write, exfiltrate, or destroy data beyond the agent's intended scope. It is a potential privilege escalation vector. Code execution must run in an isolated container with no write access outside a defined temporary directory, no network access to production systems, and a mandatory human approval checkpoint for any output that will be used outside the sandbox.

Memory poisoning is an indirect prompt injection attack: malicious instructions are embedded inside a document that the agent ingests into its vector memory. Once indexed, the embedded instruction persists and may be retrieved and executed in future tasks — potentially weeks later, with no visible trigger. It corrupts the agent's outputs silently over time. Detection requires active monitoring of what the agent retrieves from memory, not just what it produces.

Functional testing validates that the agent produces correct outputs for expected inputs. Security testing validates that the agent's guardrails block adversarial inputs — known injection patterns, system prompt extraction attempts, tool call manipulation, privilege escalation chains. The two require different methods and different expertise. An agent that has passed functional testing but not security testing has been used, not validated. The OWASP LLM Top 10 is the minimum reference framework for security testing.

A valid sandbox replicates the full production architecture — same model, same orchestration layer, same tool integrations — with isolated, non-production data and network-level restrictions that prevent outbound calls to production systems. It is not a simplified version of the agent. Adversarial tests that cannot be run safely in the sandbox cannot be run safely anywhere — and must be run before production exposure.

Three active disciplines: monitoring (continuous observation of what the agent reads, retrieves, and produces, with anomaly alerts), client-side logging (a complete audit trail of every task execution with timestamps and data source references, stored on infrastructure the organization controls), and a defined update cycle for the model, orchestration layer, guardrails, and tool integrations. In a regulated environment, the absence of any of these is a governance failure auditable independently of whether any incident has occurred.

Virtualtek designs and deploys enterprise AI infrastructure with security and governance built in from the architecture layer — covering all nine layers described in this article. As exclusive European distributor of the RAIGF™ — Responsible AI Governance Framework, Virtualtek provides the operational structure to move from a deployed agent to a governed one: environment architecture, model selection, guardrails, tool scoping, memory integrity, interface validation, security testing, sandbox design, and production governance. Explore our AI Audit and Compliance services or the RAIGF™ framework.

The Virtualtek mindset

Why pay for a Ferrari
when a BMW gets you there just as well?

Pragmatic IT engineering: the right power, calibrated to your ambitions.

Explore our architectures

Contact

contact@virtualtek.io Belgium: +32 2 315 97 86 France: +33 2 57 72 00 98
WhatsApp

Headquarters

Ruelle des Colons 14,
4252 Omal — Belgium

Offices

BE · FR · USA