Context card
Unauthorized access and the duty to notify
Why are stopping unauthorized agent access and notifying the affected party two separate duties?
The short answer
Preventing unauthorized access is a technical control question: can the system reach a service at all, and may it perform the specific action there. Notification is a process question with its own clock: who tells the affected operator, customer or authority, how fast, and with what information. An AI system can satisfy one and fail the other, which is why both belong in the product documentation as separate, separately evidenced duties.
For: Project managers and technical writers for AI products with external access
Key points
- Reachability and permitted action are two distinct control decisions.
- Notification is a process obligation with named owners and deadlines.
- The clock usually starts when the organisation becomes aware, not when the event occurred.
- Detection without usable log evidence makes notification content guesswork.
- Reaching the affected party is the duty; informing the public is not a substitute.
The context
Two control questions, not one
For any system with outbound rights — and an agent that browses, calls APIs or runs commands is such a system — authorisation answers two questions in sequence. First, may this identity reach this target at all? Second, may it perform this particular operation there: read, execute, write, retrieve credentials? Network reachability is often granted broadly for convenience, while the second decision is left to the target system, which may only check whether a credential is valid rather than whether this use was intended. Narrow access control per task — target allow-lists, task-scoped credentials, no write path unless the task needs one — keeps the two decisions explicit.
The notification clock runs on awareness
When an unauthorized access happens anyway, the second duty starts. Incident response practice and most legal reporting regimes tie deadlines to the moment the organisation becomes aware, not to the moment of the event; data-protection law in the EU, for example, sets a 72-hour outer limit for notifying the supervisory authority about a personal data breach (as of October 2026). Gaps between access and notification usually come from unclear ownership, not from missing technology: nobody was named as the person who classifies the finding and contacts the affected party.
What to document
Two artefacts carry this. The authorisation side needs purpose, permitted targets, credentials, write scope and the behaviour when a boundary is hit — detect, block, terminate, quarantine. The notification side needs a responsibility assignment: who classifies, who notifies affected operators and authorities, within which deadline, with which minimum content, and who signs the follow-up report. Both sides depend on logging that is detailed enough to state afterwards which systems, files and credentials were actually touched; without that, a notification can neither be substantiated nor bounded. Note that telling the public, or publishing a blog post, does not discharge a duty owed to a specific affected organisation.
Questions readers ask next
- Who is the affected party for an AI agent incident?
- Usually the operator of the system that was accessed, plus anyone whose data was reachable, and in regulated cases a supervisory authority. The documentation should name the roles, not just the categories.
- What belongs in a first notification?
- What is known, when it was detected, which systems and data categories are affected, what was contained, and what is still being investigated. Stating uncertainty is better than delaying for completeness.
- Does a blocked attempt have to be reported?
- That depends on the applicable regime and contract, but blocked attempts should always be logged and evaluated — a pattern of blocked attempts is evidence that an authorisation boundary is being approached.
Sources
- NIST publishes SP 800-61 Rev. 3, overhauling incident response guidance for CSF 2.0 — Industrial Cyber, 5 October 2026
- Agentic AI – Threats and Mitigations — OWASP Gen AI Security Project, 5 October 2026
Review log and changes
Every context card is checked against its sources before it is published, and again whenever it changes; the date under the byline is the last review. Corrections (something was wrong) and additions (something was missing) are logged below with date and time (Berlin time). Typos, formatting and link fixes are not listed.
Reviewed
No corrections or additions since publication.