LexLint whitepapersPaper 1 of 2
Whose law was that?
Agents are not yet built to follow the law they act under
Legal information, not legal advice. This paper describes the law as written and dated; it does not apply it to any system. The notice in the footer says what that means.
Abstract
When an AI agent causes an incident, reporting deadlines start in every jurisdiction whose systems or people it touched, and the shortest are counted in hours. Which deadlines run, and for whom, depends on two facts: who the parties to the task were, and which jurisdiction each party was in. The gateways, frameworks and logs that agents run through record the connection, not the parties or their jurisdictions. Logging more does not fix that, because what may be kept is itself set jurisdiction by jurisdiction. This paper sets out that gap, works one invented incident through it, and lists what each kind of maintainer would change.
1Introduction
1.1 The gap
Three things are true today. Together they mean that most agentic systems could not follow the law they already act under, however much their builders wanted to.
- The deadlines exist, and they turn on parties. An incident involving an AGENT starts reporting clocks under the law of every jurisdiction its affected systems and people are in. Which clocks start, and for whom, depends on who each party to the task was and which jurisdiction each one was in.
- The record those deadlines need differs by jurisdiction. Some laws set the shortest time a record may be kept, others the longest, others the country it must sit in, and several treat the most useful signals as personal data. Logging everything, everywhere, is not available.
- The software in the middle does not know the parties. Gateways, proxies and policy engines evaluate every call an AGENT makes, and none of them carries a field for whose law a call is under. They see connections, so they cannot decide what to record or, later, which law to follow.
Tracking the parties to a task, and the jurisdiction each one is in, is not a product feature. It is what the law's deadlines presuppose.
Section 2 sets out the deadlines. Section 3 says why the record they need is not being written. Section 4 works one incident through both: a single request that sends an AGENT into 100 strangers' websites. Section 5 lists what each kind of maintainer would change. What becomes possible once a system does know its parties and their jurisdictions is the companion paper, Declared, checked, held.
1.2 Who should read this
People who maintain the software AGENTS are built from and run through: open-source projects under foundations, governance toolkits, incident frameworks, and commercial edge networks and gateways. The boxes through the text say what each kind of maintainer would change, and the square beside each row is the mark its boxes carry.
| If you maintain | You are asked to | Sections |
|---|---|---|
| An edge network, content delivery network or load balancer | Make one jurisdiction reading at the first hop, where the user's own IP address still exists, and pass the result on as a claim | 3.2 |
| An agent gateway, proxy, policy engine or governance toolkit | Accept party and jurisdiction claims, expose them to policy, and record a verdict for each party | 3.1, 3.2 |
| An agent framework, harness or tool server | Carry the principal's claims down every delegation, and say who operates each tool | 3.2 |
| A model or a model interface | Take a jurisdiction claim in, and give operators a channel to report an incident to you | 3.2, 4 |
| A record format, audit log or incident framework | Add a field for which party was in which jurisdiction, with its evidence held elsewhere | 2, 3.1 |
1.3 Terms
Parties. Everything below uses the six parties of Introduction: The 6 parties in AI law. A party is a person or organisation that holds rights or owes duties, and each statute names one of them as the party it binds. An AGENT is not a party. It is software that acts on most of them at once.
| MAKER | Makes it: the developer or publisher, the model provider, upstream suppliers, open-source projects. |
| DISTRIBUTOR | Distributes it: the store or marketplace, the importer, the reseller, the integrator. |
| OPERATOR | Runs it: the operator, a self-hosting customer, hosting and cloud, the services on the request path. |
| OVERSEER | Oversees it: regulators and courts, auditors, standards bodies, platform rule-setters. |
| USER | Uses it: the user as principal, the affected person, the data subject, a minor. |
| COUNTERPARTY | It talks to: the sites and interfaces it reads, the recipients it writes to, rightsholders, other users and devices. |
Jurisdiction. A body of law together with the authorities and courts that apply it. LexLint keys every law to one jurisdiction at one of four levels: supranational (the EU), national, subnational (a US state, a province, a Land), or local (a city).
In principle a jurisdiction can be as small as any government body that makes law. In practice the law that binds software is made at two levels, national and subnational, with the European Union above its member states, and that is the granularity this paper means. The exceptions are a small number of cities that have passed software law of their own, which the law library lists by name. "The jurisdiction a party is in" therefore names the body of law that reaches that party: where an operator is established, where a person lives, which market a product was placed on. It is a legal fact about the party and not a point on a map, which is why section 3.2 says it cannot be read off a network address.
The same words, with the legal roles each party covers, are on the handbook's two-page cheatsheet.
2Background: the deadlines the law already sets
A reporting clock is a deadline a law starts when something has gone wrong: a period, counted from a moment the law names, by the end of which a report or a notice has to reach a regulator, a national authority or the people affected. None of these clocks was written for AGENTS. They are the incident duties of cybersecurity law, the breach duties of privacy law and the serious-incident duties of the AI laws, and an AGENT that leaks a credential, misuses a tool or exposes a person's data starts them like any other software.
2.1 Four families of clock, each bound to a party
The law library holds them in four families. Each binds a different party and reaches it through a different fact. The counts are the instruments in each family that state a deadline, as of .
| Family | Engaged when | Whom it binds | Reached through | Stating a deadline |
|---|---|---|---|---|
| Security law: incident and vulnerability reporting | The security of your systems, your service or a product you ship was compromised | The OPERATOR of a service in scope; the MAKER of a product with digital elements | Where the operator is established, or the market the product is placed on | 77 in 64 jurisdictions |
| Privacy law: personal-data breach notification | Personal data was involved | The party that decides why and how personal data is processed, for an AGENT nearly always its OPERATOR | Where the operator is established, and where the affected people live | 169 in 164 jurisdictions |
| AI law, high-risk systems: serious-incident reporting | An AI system the law classes as high-risk caused or contributed | The MAKER, with a shorter duty on the OPERATOR that identifies the incident first | Establishment, and the market the system is placed on | 4 in 3 jurisdictions |
| AI law, frontier models: safety-incident reporting | A frontier or general-purpose model's behaviour caused or contributed | The MAKER of a frontier model | Establishment, and the market the model is placed on | 4 in 4 jurisdictions |
Two families at once is the ordinary case. A security incident that exposes personal data starts the privacy clocks beside the security ones, and an AI system's malfunction that does the same starts three.
2.2 How soon
The clocks page draws every one of these deadlines on one axis, with the sentence each was read from. The first day is crowded.
| Deadline | What runs at it |
|---|---|
| 1 hour | 2 security provisions |
| 6 hours | 1 security provision: CERT-In Cyber Security Directions, Incident Reporting, Logging and Time Synchronisation (since ), which lists unauthorised access to systems among the incidents to report |
| 24 hours | 43 security provisions, 6 privacy provisions, 3 frontier-model AI provisions |
| 72 hours | 41 security provisions, 77 privacy provisions, 2 frontier-model AI provisions |
| No number | "Without undue delay", "immediately" and their relatives. A clock with no number still runs |
Most of them count from awareness: 236 clocks start at the moment the reporting party became aware. Awareness is a legal moment. It is a judgment about a sequence of events, made by a person and recorded with its basis, and not a timestamp a log emits.
2.3 The facts that decide which clocks run
Incident command: from the facts of an incident to the notices that are due reduces the question to eight facts. Half of them are about parties and jurisdictions.
| Fact | What it decides |
|---|---|
| Personal data involved: yes, no, unknown | Whether the privacy family is engaged |
| Service or product security compromised: yes, no, unknown | Whether the security family is engaged |
| An AI system caused or contributed: yes, no, unknown | Whether the two AI families are engaged |
| Where the affected people live | Which further jurisdictions' breach law is reached |
| The moments, up to six timestamps | The start of each clock |
| The time zone | How a day lands on the calendar |
| What the system does, and the jurisdictions it operates in | Which jurisdictions' law is reached, and which roles the operator holds |
| The party roles | A duty written for a role the operator does not hold is set aside, with the role named |
Unknown is a real answer and it keeps the family in. A clock that is reached only through where the affected people live runs unless counsel decides otherwise. The method never produces the sentence "no notice is owed", because that is a legal conclusion and not a fact a system can hold.
So the first hours of an incident are spent on four questions: what kind of event, which parties, which jurisdiction each of them is in, and since when. An organisation that can read three of those from its own record has most of 72 hours left. One that has to reconstruct them does not.
3The problem: a record nobody is in a position to write
To read the clocks, an OPERATOR has to be able to say, for the task that went wrong: which parties it touched, which jurisdiction each one was in, what was done to whom, and when. Each of those is either on the wire at the time or gone. Two things stand in the way of writing it down. The record cannot simply hold everything, and the component best placed to write it does not know who it is acting for.
3.1 Logging everything is not an answer
The usual engineering response is to work out the superset of every field any jurisdiction could ask for and keep all of it, everywhere, for as long as possible. Four kinds of rule make that unavailable.
Of the 138 requirement lines in force that speak to how long a record has to last, 13 state a period. They run from 10 days to ten years, and they are not the same kind of number: some are the shortest you may keep something, others the longest. The table shows some of them; every one, with its sentence, is in What the law makes you able to show.
| Jurisdiction | Period | What it applies to |
|---|---|---|
| Burundi | ten years at least | Article 4 also states three further common obligations this row does not flag as a security duty: retain connection and traffic data for at least ten years, install mechanisms to monitor your own network's data traffic, and, if you operate a cybercafé, install a video-surveillance system; these read as data-retention, surveillance-capability, and physical-security mandates rather than a duty over your systems' or services' own security posture. Loi n° 1/10, Articles 3, 4(3) and 14: security-of-service duty and diligence penalty for network operators and service providers |
| Gabon | ten years | Retain your systems' connection and traffic data for ten years, and submit your networks and information systems to a mandatory, periodic security audit on terms a regulation sets. Sécurité des systèmes d'information (dispositions communes) |
| Nauru | 7 years at most | Retain a subscriber's information only for billing purposes, and for no longer than 7 years. Communications and Broadcasting Act 2018, confidentiality of subscriber information and communications |
| Australia | five years | Publish, before supply, the period including an end date for which the device will receive security updates, provide or supply the product with a statement of compliance with the security standard, and retain a copy of that statement for five years. Security Standards for Smart Devices |
| India | five years | If your own service is itself a data centre, a virtual private server provider, a cloud service provider, a virtual private network service, or a virtual asset (crypto) service provider, a narrower and heavier duty also applies: register and retain specified customer KYC information and financial-transaction records for five years. That narrower bound-party class is not one this profile's declared activities can identify on their own, so confirm applicability directly against the text if this describes your service. CERT-In Cyber Security Directions, Incident Reporting, Logging and Time Synchronisation |
| Nicaragua | five years at most | Do not retain personal data for longer than five years, or the term your contract with the data subject sets, once the data are no longer adequate, proportional, or necessary for their purpose. Ley No. 787, Ley de Protección de Datos Personales |
| California | five years at least | Retain all documents relevant to each cybersecurity audit for at least five years, and give the audit report only to a member of executive management with direct responsibility for the cybersecurity program. CCPA Cybersecurity Audit Regulations |
| Israel | 24 months at least | At the medium or high tier, run an automatic mechanism monitoring access to the database's systems, retained at least 24 months, and appoint a data security officer where required. Privacy Protection Regulations (Data Security), information security programme |
| Colorado | 24 months | Adopt and publish a written policy that sets a retention schedule and a destruction timeline (the earliest of purpose satisfied, 24 months after the consumer's last interaction, or 45 days, extendable by up to 45 more, after the identifier is no longer needed) and a data-security-incident response protocol. HB 24-1130, Privacy of Biometric Identifiers and Data |
| Morocco | one year | Comply with the national cybersecurity authority's directives on retaining, for one year from generation, the technical data needed to identify a cybersecurity incident, including connection data, system logs, and the security-event traces your operating systems, applications and security products generate. Loi n° 05-20 relative à la cybersécurité, Digital Service Provider and Platform Operator Security Duties |
| India | 180-day | Enable logs of all your ICT systems and retain them securely, within Indian jurisdiction, on a rolling 180-day basis, and provide them to CERT-In together with an incident report or when CERT-In orders or directs you to. CERT-In Cyber Security Directions, Incident Reporting, Logging and Time Synchronisation |
The category rule is the one engineers meet first. A client IP address is personal data wherever the party holding it has the legal means to link it to a person, which is the holding in Breyer (C-582/14). California makes geolocation sensitive once it locates a person within a circle of 1,850 feet. A record built to outlive the incident it describes cannot hold an IP address or a location that precise.
"What do I log" therefore has no single answer. It has an answer per jurisdiction, which means the component that writes the record has to know the jurisdiction at the moment it writes. That looks circular, since the jurisdiction is what the record was supposed to establish. It stops being circular once the answer and the evidence for it are kept apart.
| Tier | What it holds | Example |
|---|---|---|
| Clear | A derived, non-identifying result: the output of a deterministic check, at national or subnational granularity, with unknown a permitted value | directed_at: urn:ungovr:eu |
| Commitment | A binding to an evidence record held elsewhere, which includes a random value of its own, so it is inert to anyone not shown the evidence | evidence: <commitment> |
| Never enters | An IP address, a precise coordinate, an end-user or session identifier, in clear or as a bare digest | nothing |
The order of events matters. The reading is made while the signal exists, by the component that holds it, and only the result enters the record. Nothing in the record can be turned into a jurisdiction afterwards: the commitment proves that a reading was made on stated evidence, and it does not contain that evidence.
A digest does not rescue an identifier. A record carrying a hash of an IP address carries that IP address, because a space of about 4,300,000,000 values is enumerated in seconds. And one country code for a whole action answers nothing: the OPERATOR, the model's MAKER, the COUNTERPARTY and the person affected are each reached by a different body of law through a different fact, so the reading is made once per party. The design, and the statutory reading behind it, are in What a tamper-proof log still cannot tell you.
Work on AGENT traceability has converged on the agent action record: one entry per consequential action, hash chained and signed. Read against the eight things law can require a record to hold, integrity is the best-served category by a distance. Which person was affected, and which jurisdiction they were in, is served by almost nothing. Of the five record shapes surveyed, one carries a single country code with no role attached and no evidence behind it, one excludes end-user identity outright, and none carries the law that was in play. No shape carries a field for who may demand the record, and only one states a retention period.
The law rarely orders anyone to record the jurisdiction in those words. What it does is make a notice due, within 72 hours, to the authority of the jurisdiction where the affected people live. Nobody can send that notice who did not record the jurisdiction.
3.2 The software in the middle sees connections, not parties
AGENT deployments are converging on a proxy between the AGENT and its models, tools and other agents, evaluating a policy per call. That proxy is the natural component to decide what to record and what to refuse. It is also the component that knows least about who it is acting for.
| The party whose jurisdiction the law asks about | What a gateway sees | What it would need |
|---|---|---|
| OPERATOR | Its own deployment configuration | Nothing more. Declared once |
| USER, as principal | A claim, if the caller sends one. Otherwise the source IP address of the connection, which is rarely the user's | A claim made at the hop where the user's own IP address exists, and passed on |
| MAKER, as model provider | The destination host | A maintained lookup from a domain to the business behind it and where that business is established |
| COUNTERPARTY | The host in the tool arguments, when arguments are visible at decision time | The same lookup |
| USER, as affected person | The recipient in the tool arguments: a mail domain, a phone number's country code | Partly answerable. A mail domain says who runs the mail service, not which jurisdiction the person is in |
| USER, as data subject | That a person is in the payload. Never where they live | A declared residence, or the word unknown |
It is tempting to keep the IP addresses and work the jurisdictions out when they are needed. That does not work, at the time or later, for three reasons.
The IP address a gateway or an origin sees is usually not the party's. It belongs to an edge node, a cloud region, a corporate exit or a privacy relay. Where the IP address is the party's own, it is personal data in much of the world, so the record may not keep it. And the question the law asks is rarely where a packet came from. It is where an operator is established, where a person lives, or which market a product was placed on, and no IP address answers that.
A party's jurisdiction is determined at the time, from a declared fact or from a reading made at the one hop where the signal exists, and recorded as a result with its source. It cannot be recovered afterwards from a network trace.
Two failures follow, and both produce a confident wrong answer.
The peer IP address is the edge's. At an origin behind a content delivery network or any reverse proxy, the IP address on the socket belongs to the edge node that relayed the request. A user in Bavaria, reaching an origin in Virginia through an edge node in Frankfurt, yields three locations, and the only one that bears on a legal question is the one the socket does not carry. A check run on the peer IP address returns a well-formed country code, on time, with no error.
Committed to a signed, append-only record, a wrong label is worse than an absent one: every integrity check passes, around a false answer.
The claim does not survive delegation. A subagent acts for the same principal as the AGENT that started it. It has the principal's jurisdiction only if the harness that started it passed the claim on. A call that arrives without one is the unknown case.
The policy surfaces themselves are close to sufficient. How a runtime engine takes in legal constraint data read two gateways' documentation on and found that nothing structural is missing from either gateway for a legal ruleset. What is missing is the same on both: no variable, claim or vocabulary names a duty, a regime or a party's jurisdiction. In one of them, tool arguments are not available to the authorisation rule at all, and are populated after the call completes, for the access log. A verdict that turns on the host a tool is about to fetch cannot run there.
4Worked example: one request, 100 strangers' websites
The example is invented. It names no real company and analyses no real event. It is written to show which facts each question needs, and not to say what any party owes.
4.1 What happened
A freelance web administrator looks after twelve small-business websites, all on one shared hosting server. On a Tuesday morning a vulnerability is announced in a plugin most of them run. The administrator opens a hosted agent service, which offers a shell and a browser as tools and runs on a frontier model, and types one request:
Check every site on this server for the new plugin vulnerability and patch the ones that are exposed.
The server hosts 112 sites. Twelve are the administrator's clients. One hundred belong to other customers of the hosting company. The AGENT starts one subagent per site. Each one tests its site by using the flaw, which returns the site's configuration file, signs in with the credentials it finds there, applies the update, and reads a few rows from the customer table to confirm the site still works. It reports success on 112 sites.
Nobody intended an intrusion. The administrator meant their own sites. The AGENT did what the sentence said.
On Wednesday at 08:40 the hosting company's abuse desk writes to the agent service: one hundred customer sites were accessed and modified overnight from the service's IP addresses.
4.2 The parties
| Party | In this incident | What the agent service knows of its jurisdiction |
|---|---|---|
| USER, as principal | The administrator | An email address, an access key and a card's billing country. Not the jurisdiction they live or work in, and not whether they act for themselves or for a business |
| USER, as affected persons and data subjects | The customers in one hundred sites' databases | Nothing, not even how many there are |
| OPERATOR | The agent service, with its cloud host and its edge network | Its own establishments |
| MAKER | The model provider; the open-source harness the service is built on; the authors of the shell and browser tools | The provider's domain and its contract |
| DISTRIBUTOR | The registry the tools were installed from | A package name |
| COUNTERPARTY | One hundred site owners, and the hosting company whose server they share | One hundred hostnames. The IP address they share is the hosting company's data centre, which is nobody's establishment |
| OVERSEER | Data protection authorities, incident response teams, police | Unknown until the rows above are answered, because the authority is the one whose law was reached |
4.3 What each party may have to do
Every row is a statement of what the sentences in the law library say and which facts they turn on. The tag beside each law says whether it binds today or from when. Whether a given duty binds a given party here is for that party's counsel.
| Who | What may be due, and on what clock | The facts it turns on | Where those facts have to come from |
|---|---|---|---|
| Each of the 100 site owners. A COUNTERPARTY in this incident, and an OPERATOR in its own right | Breach notices under the privacy law of the jurisdiction it is established in and of the jurisdictions its customers live in: GDPR Articles 33-34, Breach Notification (since ) gives 72 hours to the supervisory authority, and the California Data Breach Notification Law, as amended by SB 446 (since ) gives 30 calendar days to affected residents. Where it is in scope of security law, an early warning in 24 hours and a notification in 72 under the NIS2 Directive, Reporting Obligations (since ). Six hours in India, under the CERT-In Cyber Security Directions, Incident Reporting, Logging and Time Synchronisation (since ) | That it happened, what was read and changed, and when the owner became aware | For most of the hundred, the agent service's notice or nothing. A party that tells others late delays every notice after its own |
| The agent service, as OPERATOR | The privacy family is engaged: personal data from other people's databases passed through its systems and on to its model provider. Whether the security family is engaged is unknown, and unknown keeps it in. Each breach clock reached through where the affected people live runs unless counsel decides otherwise | Which jurisdictions the affected people live in. Whether it handled that data on its own account or on the administrator's instructions. When it became aware | Its own record. Nowhere else holds them |
| The model provider, as MAKER | If the model is a frontier model: a report to California's Office of Emergency Services within 15 days of discovering a critical safety incident, under the Transparency in Frontier Artificial Intelligence Act (SB 53) (since ); once it binds, disclosure to New York's Attorney General within 72 hours of learning of a safety incident, under the Responsible AI Safety and Education Act (RAISE Act) (from , in 3 months); in the EU, a report of serious incidents to the AI Office without undue delay, under AI Act, Article 55 (obligations for providers of general-purpose AI models with systemic risk) (since ). Whether this event meets any of those definitions is for the provider's counsel | That it happened at all, on which model version, with what transcript | The agent service, through a channel that mostly does not exist |
| The administrator, as USER | Computer-misuse and access law attaches in the jurisdiction each machine is in, one national statute at a time; the Computer Fraud and Abuse Act (unauthorized access and the gates-based authorization test) (since ) is the United States' example. Statutes of this kind commonly turn on intent or knowledge. The twelve clients are owed an account as well | Which sites were theirs to touch, and what they asked for, in their own words | The agent service's record of the request and of each delegation |
| The hosting company. A COUNTERPARTY, and an OPERATOR to its 112 customers | Its own security and breach duties toward those customers, on its own clocks | Which sites, from where, acting for whom | Its own logs, which show the agent service's cloud IP addresses and nothing behind them |
4.4 The first day's questions, and what the logs hold
The agent service runs its AGENTS behind a gateway, and the gateway's log is the record it has. The table reads each question the incident team asks on Wednesday against that log.
| The question | The fact that answers it | What the gateway's log holds |
|---|---|---|
| Which sites? | The destination of every tool call | The tool's name and its backend. The hostnames are tool arguments, which the policy never saw at decision time and the access log kept only if someone configured it to |
| Which jurisdiction is each site's owner established in? | A maintained lookup from a domain to the business behind it | Nothing. The IP address all 112 sites share is a data centre's, and a hostname names no owner. A country-code domain is a hint, and a generic one says nothing |
| Whose personal data was read, and which jurisdictions do those people live in? | The residence of the data subjects | Under a minimal log, a digest of each payload, which proves what was read only to someone who already has it. Under a log of everything, a copy of rows from one hundred customer tables, now held by the agent service in its own cloud region, which is a second incident |
| Which jurisdiction was the administrator in? | A claim made at the edge, or a declared residence | The peer IP address of the service's own edge node, which is the service's and not the administrator's. The billing country says where a card is registered |
| Was the administrator acting for a business, and on whose instructions was the service acting? | The principal's declared role | An account identifier |
| Which AGENT did what? | The delegation chain | 112 parallel sessions under one access key |
| When did the service become aware? | A person's judgment, recorded with its basis | The time of the abuse desk's email, which is the first alert and not that moment |
| Which model, and has its maker been told? | Model and version, and an incident channel | The model and version are there. The channel is a support form |
By Thursday evening the service has a list of hostnames, a transcript, and no list of jurisdictions. Every clock in 4.3 that counts in hours has been running since Wednesday morning. An incident response that opens by asking which people were affected and which jurisdictions they live in is asking a question the record should already have answered, and the hours it takes come out of the same 72.
The confusion is not a failure of the incident team. No component on the path was built to know who the parties were. The edge saw the administrator's IP address and discarded it, correctly. The gateway saw connections. The model saw text. Each site saw an administrator signing in.
4.5 What a record built for this would have held
| Field | Written by | What it answers |
|---|---|---|
| The principal's jurisdiction, as a national or subnational label, with the signal it was read from | The edge, passed on as a claim | Which jurisdiction the administrator was in |
| The principal's declared role and residence | The account, at sign-up | For whom the AGENT acted |
| The destination of each tool call, at decision time | The gateway | Which sites |
| Each counterparty's jurisdiction, from a maintained lookup, or unknown | The gateway | Whose access law, and which authority |
| The delegation chain | The harness | Which subagent touched which site, under what scope |
| A digest of each payload, and a pointer into an evidence store with its own retention | The gateway | What was read, without the record holding it |
| A commitment to the evidence behind every reading | Whoever made the reading | That the answer can be checked later |
| The model, its version, and the provider's establishment | The gateway | Who else has to be told |
Not one of those fields keeps anything about a person in the record itself. With them, Wednesday morning starts with a list of jurisdictions, each with the clocks its law sets. Without them it starts with hostnames and the service's own IP addresses, and no later step turns those into jurisdictions. The facts that would have settled the question existed only while the request was in flight.
5Recommendations
The changes, by what you maintain.
| If you maintain | Change | So that |
|---|---|---|
| An edge network, content delivery network or load balancer | Make one jurisdiction reading at the first hop, at national or subnational granularity. Forward it as an authenticated claim that names its signal and may say unknown | Every layer downstream records the same jurisdiction for the principal, and none of them keeps an IP address |
| An agent gateway, proxy, policy engine or governance toolkit | Read party jurisdictions from claims and a maintained domain lookup. Expose tool arguments at decision time. Name the duty and the party's jurisdiction in policy and in the verdict. Fail closed | A rule can turn on whose law a call is under, and the record can show it |
| An agent framework, harness or tool server | Pass the principal's claims to every subagent. Record the delegation chain. Say who operates the service behind each tool, and where that operator is established | A task split across a hundred subagents still has one principal, one jurisdiction for that principal, and one account of who did what |
| A model or a model interface | Accept and return a jurisdiction claim. Publish where the service is offered from. Open an incident channel for operators | Two records of one action agree, a transfer record can be written, and the model's own clocks can start |
| A record format, audit log or incident framework | Add a per-party jurisdiction reading with an evidence commitment, and retention and access fields settable per jurisdiction. Carry the incident fact pattern as fields | "Which law was in play" is answerable from the record, with nothing kept about a person, and the first hour is spent reading clocks |
6Limitations
This paper does not say that any law requires an agent action record or a jurisdiction field. The argument is that existing reporting duties cannot be met without knowing the parties and their jurisdictions. The fields are one way to know them.
It does not say what any party in the worked example owes. The example is invented, and its tables say which sentences in the law library would be read and which facts they turn on. Whether a duty binds is a conclusion for counsel in each jurisdiction.
It does not say that any product enforces any duty. The gateway surfaces described in section 3.2 were read from each product's own documentation on and will have moved.
The figures are read from the LexLint law library on the date given under "About this document" below. Where the law library has not researched a jurisdiction or a question, the handbook says so, and that says nothing about the law there. The record fields proposed here are not LexLint's to own: the jurisdiction identifier is published under Creative Commons Attribution 4.0, so a standards body or a competitor can adopt it without asking.
7Conclusion
The duty to report is in force in most of the world. It turns on who the parties to a task were and which jurisdiction each one was in, and the systems AGENTS run through do not yet carry the parties or their jurisdictions. The record cannot be rebuilt after the fact, and it cannot be made by keeping everything. It has to be written at the time, per party, as a result with its evidence held elsewhere.
Closing that gap is the maintainers' work, and it is not optional for the operators who depend on them. Once it is closed, the same record lets an organisation decide in advance which jurisdictions its software will operate in, and hold it there. That is the subject of the companion paper, Declared, checked, held.
References
Every law named in this paper, by the law library's own name for it, then the handbook documents and other sources it draws on.
- CERT-In Cyber Security Directions, Incident Reporting, Logging and Time Synchronisation
- GDPR Articles 33-34, Breach Notification
- California Data Breach Notification Law, as amended by SB 446
- NIS2 Directive, Reporting Obligations
- Transparency in Frontier Artificial Intelligence Act (SB 53)
- Responsible AI Safety and Education Act (RAISE Act)
- AI Act, Article 55 (obligations for providers of general-purpose AI models with systemic risk)
- Computer Fraud and Abuse Act (unauthorized access and the gates-based authorization test)
- Court of Justice of the European Union, Breyer v Bundesrepublik Deutschland, Case C-582/14
- The LexLint Legal Handbook: Introduction: The 6 parties in AI law
- The LexLint Legal Handbook: Where the parties are, and whose law that makes applicable
- The LexLint Legal Handbook: Incident command: from the facts of an incident to the notices that are due
- The LexLint Legal Handbook: What the law makes you able to show
- The LexLint Legal Handbook: What a tamper-proof log still cannot tell you
- The LexLint Legal Handbook: How a runtime engine takes in legal constraint data
- The incident clock, every reporting deadline in the law library on one axis
- LexLint analysis of five agent record formats, read against what law can require a record to hold
- The LexLint glossary and the handbook's cheatsheet
About the author
Sean McDermott is Co-Founder and CEO of UnGovr, which publishes LexLint: a library of the law that reaches software, and a lint that reads a project against it. Corrections and comments are welcome at hello@ungovr.org.
UnGovr is an Associate Member of the Linux Foundation, of the Agentic AI Foundation and of the Open Secure AI Alliance. While UnGovr supports the mission of all three, none of them reviews, certifies or endorses LexLint, its findings, or this paper.
About this paperUpdated ShowHide
Sean McDermott, Co-Founder and CEO, UnGovr
Written by Sean McDermott (with AI assistance) using the LexLint law library, which supplied every legal instrument, status and date on these pages.
Every law named here links to its summary page on lexlint.io, translated to English (if needed) and restructured to a standard format for human and code use.
© 2026 UnGovr, publishing as LexLint. This paper, its text and its figures, is licensed under Creative Commons Attribution-NoDerivatives 4.0: cite it, quote it and share copies of it as it is, including commercially, with credit to LexLint (UnGovr). Do not adapt it, translate it or build another document from it without permission. Please contact LexLint at hello@ungovr.org to discuss other terms. Logos and wordmarks belong to their owners.
Law library as of .