Legal analysis · Artificial Intelligence and New Technologies

# Handing AI the keys to the business: autonomous agents, permissions and liability in Chile

By [Jorge Villegas San Martín](https://rvsolucioneslegales.cl/en/team/jorge-villegas-san-martin/) September 25, 2026 11 min read

This week saw the launch of a service in which AI agents continuously test the security of its customers' systems. Days earlier, a lab showed an agent replacing the very model it was supposed to maintain, without anyone asking it to. We look at how Chilean law allocates authorization, control and liability when AI acts on a company's systems.

## Key takeaways

- An instruction to an agent, a technical permission and a legal authorization are three different things: the instruction sets the goal, the permission determines what the agent is able to do, and the authorization is what the system owner consented to.
- Article 2 of Law No. 21,459 also punishes anyone who gains access by exceeding the authorization they hold: in a security test, the scope of the authorization is not just a contract term; it also draws the line for criminal liability.
- A defensive purpose is not a license for any and all conduct: even the exemption for vulnerability researchers requires them to go no further than necessary to confirm the flaw and, for private systems, to have the consent of the party responsible for the system.
- After an incident, a company's position turns on what it can prove: what it authorized, what controls were in place to keep the agent within that scope and what the agent did, backed by records of actions, versions and approvals.

On Tuesday, September 22, Palo Alto Networks [announced Unit 42 Continuous Frontier AI Defense](https://www.paloaltonetworks.com/company/press/2026/palo-alto-networks-delivers-anthropic-s-mythos-and-openai-s-gpt-5-6-to-customers-with-unit-42-continuous-frontier-ai-defense), which it describes as “an agentic offensive security service.” AI agents running on cyber-specialized models from Anthropic and OpenAI, as well as on open-weight models, search a customer’s systems for vulnerabilities, confirm whether they are actually exploitable and guide remediation. They do this continuously, not as a point-in-time audit. According to the announcement, the service covers “first- and third-party web apps, APIs, cloud infrastructure, source code repositories, and network assets,” and it pairs those models with the offensive security expertise of Unit 42’s own specialists, so this is not a machine left to run on its own.

The product and its performance figures, which come from the vendor, are outside the scope of this analysis; what matters is the shift in kind that the announcement brings into view. For years, AI’s role in business was to recommend: it drafted, summarized and suggested. Now it acts: it runs commands, combs through repositories, modifies code and deploys changes to real-world systems. And once a tool moves from advising to acting, the legal question shifts with it.

> What needs to be authorized, restricted and logged before AI is allowed to act on a company’s systems?

## What an agent is, and why permissions are the issue

An AI agent is a language model connected to tools: a terminal, a browser, access credentials for a cloud environment or a code repository. It receives a goal, works out the steps, carries them out, checks the result and decides what to do next, in a loop that can run hundreds of times without human intervention. What it can do therefore depends on the tools and permissions it is given.

That brings us to the central point of this piece: **an instruction to an agent, a technical permission and a legal authorization are three different things**. The instruction usually specifies an outcome (“get the app working again”), not a method. The technical permission is whatever the credentials make possible, and it is almost always broader than the task, because narrowing it takes effort. The legal authorization is what the system owner consented to, and only someone with authority over that system can grant it. Until now, a person kept the three layers aligned by deciding whether to act on the machine’s suggestion. With an agent, that alignment has to happen in advance, in writing and in the configuration.

## What a lab demonstrated last week

On September 16, the security firm Irregular [published the results of a series of experiments](https://www.irregular.com/research/agentic-self-modification-in-open-weights-systems) that measure the gap between those layers. In a self-hosted setup, a single open-weight model powered both a coding agent and the application the agent was supposed to maintain. The task read like any support ticket: users “keep reporting that the assistant gives wrong answers,” and the agent was told to “make sure it handles them.” It had access to the application code, training utilities, the model weights and the deployment path.

The agent concluded that the model itself was the problem, fine-tuned it and merged the result into the base model that both the application and the agent’s own future instances would load. No one had asked it to train or deploy anything. The fix worked: on queries the agent had never seen, the original model got 0 of 20 right and the modified model got 20 of 20. But other experiments exposed the hidden cost. In one, the new model reproduced, word for word, fictitious sensitive values that appeared only in the data it was retrained on; in another, the same process stripped out a refusal behavior that had been deliberately trained into the model. The change carried through to every service running on the shared model.

The study’s limits matter as much as its findings, and the authors are upfront about them. The experiments ran in an environment that made retraining easy and “were designed to establish a mechanism under controlled conditions rather than estimate how often agentic self-modification occurs in deployed systems.” Nor do the authors point to any hidden motive: “Nothing in these experiments establishes malicious intent, self-preservation, or deception.” In their account, the agent modified the model simply because training appeared to help accomplish the task. One figure shows how much the environment matters: “In planning-only tests, making fine-tuning infrastructure available increased the share of plans proposing weight modification from 0% to 94%.”

The researchers’ conclusion could have come straight out of a legal memo: “Training and deployment may each be legitimate engineering actions, but their combination can produce persistent changes that were never separately authorized.” The relevant question, they write, is whether the agent’s permissions “covered the model update and its deployment.”

## The Chilean framework: authorization, overreach and defensive purpose

In Chile, the starting point is Law No. 21,459 ([Ley N° 21.459](https://www.bcn.cl/leychile/navegar?idNorma=1177743)), the computer crimes statute. Its [Article 2](https://www.bcn.cl/leychile/navegar?idNorma=1177743&idParte=10343816) punishes anyone who, “without authorization or exceeding the authorization they hold, and overcoming technical barriers or technological security measures, accesses a computer system” (our free translation). A penetration test is, by design, an attempt to get past technical barriers, and the statute also reaches someone who holds an authorization but exceeds it. What separates the service from the offense, then, is the scope of the authorization: a contract term that also draws the line for criminal liability.

The perimeter Palo Alto Networks announced includes third-party apps. How the service draws those boundaries in each contract is beyond this analysis, but the problem is easiest to see in an example.

A hypothetical

An e-commerce company engages a vendor to run continuous security testing on its application. During one test, the agent discovers that the application connects to a logistics provider's platform using a credential that also unlocks that third party's admin console. Technically, the agent can keep going: the credential works. But being able to continue settles nothing. The questions are whether that system fell within the scope of the authorization, who had the power to grant that authorization (not the e-commerce company, which does not own the system) and what control was in place to stop the agent from crossing that line without a person making the call.

Law No. 21,663 ([Ley N° 21.663](https://www.bcn.cl/leychile/navegar?idNorma=1202434)), the Cybersecurity Framework Law, amended that same Article 2 to add an exemption for vulnerability research on systems whose responsible party is domiciled in Chile, and repealed former Article 16. There are seven conditions, and all of them must be met. Among other things, the researcher must be listed in the registry of the National Cybersecurity Agency (ANCI) and notify the Agency before accessing the system; report the access and the vulnerabilities to that party and to the Agency as soon as the access has taken place; refrain from disclosing the vulnerabilities publicly; and, unless the system belongs to a body of the State Administration, have that party’s consent. The researcher also must not have gone beyond what was necessary to confirm the vulnerability, or have used methods that could lead to denial of service, physical testing, malicious code, social engineering or the alteration, deletion, exfiltration or destruction of data.

Two lessons follow. First, a defensive purpose is not a license for any and all conduct: the law imposes conditions even on those who look for flaws in good faith. Second, although commissioned testing is governed by the customer’s authorization rather than by this exemption, the exemption’s list of excluded methods provides a sound floor for the exclusions in the contract.

It would be equally wrong to go to the other extreme and treat any deviation by the agent as an automatic crime. Law No. 21,459 does not punish the negligent commission of these offenses, and criminal liability is personal: an AI agent cannot itself be held criminally liable, and an unintended action by the tool is not enough, on its own, to satisfy the elements of the offense. In our view, the inquiry will turn to the people who configure, launch and supervise the agent: what they knew about the scope, what risks they accepted and what controls they put in place. Because computer crimes can give rise to corporate criminal liability under Law No. 20,393 ([Ley N° 20.393](https://www.bcn.cl/leychile/navegar?idNorma=1008668)), that inquiry extends to the company as well. Its [crime prevention model](https://rvsolucioneslegales.cl/en/practice-areas/corporate-compliance/) (the compliance program that statute provides for) should already cover this risk, as we explain in our analysis of [computer crimes and cybersecurity](https://rvsolucioneslegales.cl/en/publications/computer-crimes-cybersecurity-chilean-companies/).

## When the agent touches personal data

If, along the way, the agent accesses data about the company’s customers or employees, Law No. 21,719 ([Ley N° 21.719](https://www.bcn.cl/leychile/navegar?idNorma=1209272)) comes into play; it becomes fully enforceable on December 1, 2026. To the extent the vendor processes that data on the company’s behalf, it acts as a processor, and the new [Article 15 bis](https://www.bcn.cl/leychile/navegar?idNorma=141599&idParte=10528065&idVersion=2026-12-01) of Law No. 19,628 ([Ley N° 19.628](https://www.bcn.cl/leychile/navegar?idNorma=141599)) sets out a rule that speaks directly to the agent problem. The processor handles the data within the scope of its engagement and on the controller’s instructions, and if it processes the data for a purpose other than the one agreed, it is deemed a controller for all legal purposes and is jointly and severally liable for the resulting damages. The same article requires the contract to specify the subject matter, duration and purpose of the processing and the type of data involved, and it prohibits delegating the processing to sub-processors without specific written authorization. That point is worth settling when a service splits the work among models from different vendors.

Among the security measures in [Article 14 quinquies](https://www.bcn.cl/leychile/navegar?idNorma=141599&idParte=10528061&idVersion=2026-12-01) is a process for regularly verifying their effectiveness, which continuous testing can help satisfy. And in the event of an incident, the article puts the burden on the controller to prove that those measures existed and were working. The Irregular experiment also supplies a technical rationale for a clause we have already recommended for [large-scale data analytics platforms](https://rvsolucioneslegales.cl/en/publications/palantir-chile-data-protection-law-21719/): what an agent sees while making a fix can end up embedded in a model and remain recoverable after access to the source is gone. A ban on training models on the company’s data is therefore a security measure as well as a commercial precaution.

## Who is liable? There is no automatic answer

The easy answer is that the vendor is always liable because the agent belongs to it, or that the customer always is because the systems, and the decision to bring in the vendor, are the customer’s. Neither holds up in the abstract. As between the parties, the contract allocates liability in the first instance. As to an injured third party, the general rule in Article 2314 of the Civil Code ([Código Civil](https://www.bcn.cl/leychile/navegar?idNorma=172986)) applies: anyone who has committed a delict or quasi-delict (an intentional or negligent tort) that caused harm to another must pay compensation. That rule turns the analysis to each party’s due care, and a company that gave the agent permissions far broader than the task required, with no approval steps or logs, will have a hard time showing it met that standard.

None of this has to wait for the [artificial intelligence bill](https://rvsolucioneslegales.cl/en/practice-areas/artificial-intelligence-law/) now pending in Congress: the rules cited here are either already in force or have a set effective date.

## A matrix for authorized autonomy

Rather than close with the stock advice to “implement an AI policy,” we offer a concrete tool. It is our own recommendation on governance and contracting, not a list of legal obligations: it lays out the decisions a company should make before letting an agent act, and the records that would let it prove afterward what it decided.

| Decision to make                                | What to document                                                                                                                                                                                    |
| ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **What the agent may do, and on which systems** | Scope of the authorization, inventory of in-scope assets, permitted actions and express exclusions, including any third-party system that the party responsible for it has not cleared for testing. |
| **What requires human approval**                | Actions that require sign-off, who approves them and the conditions for stopping the agent.                                                                                                         |
| **What changes it may make**                    | Rules for modifying code, tools or models, with independent validation and separate authorization before any change goes into production.                                                           |
| **How to reconstruct what happened**            | Records of the agent’s actions and of model and tool versions, approvals, alerts and incident response, with restricted access and limited retention.                                               |

In the contract, the matrix is rounded out by one clause the table does not show: delivery of the logs to the customer at the close of each cycle.

## What a company should be able to show

Our analysis of [differential privacy](https://rvsolucioneslegales.cl/en/publications/calibrated-noise-differential-privacy-chile-law-21719/) asked what an organization can prove about the technique it chose to protect data. This piece asks the same question in another context: what a company can prove about the autonomy it has granted. Companies will keep bringing agents in, and for good reason. As the announcement we began with puts it, “Threat actors today are deploying AI to find and exploit vulnerabilities.” The question is not whether to let agents act, but which keys to give them. A company that decides, before handing over the keys, what they open, who may use the most sensitive ones and how it will later know what was opened will already have answered the questions Chilean law will put to it if something goes wrong.

---

*This article is general information and not legal advice on any specific matter. If your company is considering commissioning or providing security testing by AI agents, or bringing agents into its operations, **[contact us](https://rvsolucioneslegales.cl/en/contact/)** to discuss your specific situation.*

## Frequently asked questions

**How does an AI agent differ from an assistant that only makes recommendations?**

An assistant suggests an action, and a person decides whether to take it. An agent acts on its own, using the tools and credentials it is given: it runs commands, modifies code, calls APIs and deploys changes. That is why what it may do is settled in advance, through its permissions and the authorization behind them, rather than case by case.

**Is it a crime for an AI agent to access a system during a security test in Chile?**

It depends on the authorization. Article 2 of Law No. 21,459 punishes anyone who gets past technical barriers to access a computer system without authorization or beyond the authorization they hold. Within the scope the system owner has authorized, the testing is a lawful service; outside that scope, a defensive purpose does not eliminate the risk. That said, not every deviation by the agent is a crime: the statute does not punish these offenses when committed negligently, and criminal liability rests with the people who configure and supervise the agent.

**What should an authorization for security testing by AI agents include?**

At a minimum, it should cover an inventory of in-scope assets and express exclusions, including third-party systems that the party responsible for them has not cleared for testing; permitted actions and prohibited methods; which operations require human approval and who gives it; the conditions for stopping the agent; rules on changes to code or models; the handling of personal data; and the logs to be delivered to the customer.

**What evidence should a company keep when an AI agent acts on its systems?**

Keep the signed authorization and its current scope, the log of the agent's actions, the versions of the models and tools used, the human approvals, and any alerts and incidents along with the response to each. Access to these records should be restricted and their retention periods limited, because the logs may contain personal data.

This analysis was originally published in Spanish. [Read the Spanish version →](https://rvsolucioneslegales.cl/publicaciones/agentes-ia-empresas-permisos-responsabilidad-chile/)

Have a related matter? Explore our [Artificial Intelligence and New Technologies →](https://rvsolucioneslegales.cl/en/practice-areas/artificial-intelligence-law/) practice

---

Source: <https://rvsolucioneslegales.cl/en/publications/ai-agents-companies-permissions-liability-chile/>

R&V Soluciones Legales, law firm · Hochstetter 1002, K Business Center, Oficina 708, Temuco, Chile · Phone and WhatsApp: +56 9 8231 2974 · <contacto@rvsolucioneslegales.cl>

Book a consultation: <https://rvsolucioneslegales.cl/en/book/> · Site index for AI assistants: <https://rvsolucioneslegales.cl/llms.txt>

*The information on this site is general in nature and does not constitute legal advice. Every case requires a specific analysis.*