DEV Community: Codacon

Next-Concept Modeling: When AI Stops Writing Left to Right

Codacon — Thu, 05 Nov 2026 18:16:13 +0000

On October 9, a Stanford team published Next-Concept Modeling (NCM). It is a research paper about speed, not security, and nothing in it ships in a product you use today. It is still worth ten minutes of a security leader's time, because it shows where language model architecture may be heading, and several controls in production now quietly depend on the architecture it moves away from.

What the paper does

Today's large language models are autoregressive: they write one token at a time, left to right, and each token depends on the ones before it. Diffusion language models, the main research alternative, start with a full-length draft and refine every position over many steps.

NCM does neither. It compresses text into a short hierarchy of codes, from coarse to fine. The first level is a handful of codes that carry the gist; each following level adds detail, up to one code per token. The model generates one level at a time and predicts every code within a level in parallel. A separate decoder then turns the finest level back into words.

The reported results, at research scale:

Speed. 21 times faster than the strongest diffusion baseline on one benchmark, 10 times on web text, 31 times on news summarization, at comparable quality.
Steps. A summary in 8 model passes, against 128 for the diffusion baseline.
Reasoning. Better than autoregressive and diffusion baselines on Sudoku at every difficulty, with fewer passes.

What it is not

The main experiments use models of about 100 million parameters, and the scaling study stops at 725 million. Production assistants are hundreds or thousands of times larger. The authors call their scaling results preliminary, and on translation the method trails autoregressive models unless it spends more compute. The paper links no released code.

So nothing changes this quarter. What changes is the question you ask vendors from now on, because the pressure behind this work is real: as the paper puts it, inference is becoming "a dominant computational workload." Every lab is looking for ways to generate text without paying for one pass per token.

Three controls that assume left to right

Streaming output filters

Many guardrails inspect output as it streams and cut the response off when it crosses a line. That works because the first tokens are final the moment they appear. In a coarse-to-fine model, no readable text exists until the last level is decoded, and the whole response arrives at once. A filter that relied on stopping early becomes a filter on the complete output. That is not weaker by itself, but its latency, cost, and failure mode change, and the vendor's test results were measured on a different architecture.

Constrained output for tool calls

Agents call tools by emitting structured output, usually JSON. Many stacks guarantee that structure by constraining decoding: at each step, tokens that would break the schema are forbidden. That technique is built on next-token prediction. When the text is produced by decoding codes, the guarantee has to come from somewhere else, such as validation after generation and a retry. If your agent's safety case says "the model cannot emit an invalid tool call," find out which mechanism makes it true.

Token-level signals: confidence and watermarks

Some hallucination detectors read per-token probabilities, and well-known statistical watermarks for AI-generated text work by biasing each token's choice based on the tokens before it. Both assume a model that picks tokens one after another. Neither carries over automatically to a model whose words come out of a decoder. If you rely on a provider's watermark for provenance, or on log probabilities for confidence scoring, ask whether it still holds when the provider changes models.

A new failure: right idea, wrong word

The paper's appendix documents an error class worth naming. The decoder that turns codes back into text is very accurate, 99.99% of tokens on web text, but its rare mistakes are not random. It swaps named entities, shifts numerals, and garbles markup: Melbourne becomes Brisbane, one year becomes the next.

This is not a hallucination. The model can have planned the right content and still output the wrong city. In casual text, it is noise. In a summary of a contract, an incident timeline, or a payment instruction, names, dates, and amounts are exactly the tokens that matter.

The control is the same one you should already have for any AI output that moves money or makes a commitment: check names, numbers, and identifiers deterministically against the source before anyone acts on them. A model that is usually right is not a control.

Cheaper generation, more agents

The quieter consequence is cost. If text generation becomes ten times cheaper, inference stops being the brake on how many agents a team runs and how often they run. Volume will grow faster than review capacity. Organizations that already keep an AI agent inventory and a near-miss register will see the growth. The others will find it during an incident.

What to do now

Add one field to your AI inventory and vendor questionnaire: how the model generates text (autoregressive, diffusion, or other), and whether that changed since the last review.
Find the controls that depend on it: streaming filters, constrained decoding, log-probability confidence, watermarks. For each, write down what happens if the provider swaps the architecture.
Verify facts in high-stakes outputs deterministically: names, amounts, dates, and identifiers, compared against the source, whatever the model.

How we help

Our GenAI Security Readiness Assessment lists the controls around your AI systems and the assumptions each one rests on, including the ones about how the model works. When a provider changes models, you know which controls to retest.

Three questions to test yourself

Which of your AI guardrails would stop working, or work differently, if the model produced its whole answer at once?
When an agent emits a tool call, what guarantees its structure: the model, the decoder, or a validator you control?
Which AI outputs in your organization carry names or amounts that someone acts on without checking the source?

The AI Supply Chain Map: Where LiteLLM 1.107.0 Should Have Been Caught

Codacon — Wed, 04 Nov 2026 18:14:14 +0000

On October 21, a compromised LiteLLM 1.107.0 release was published to PyPI. It also reached the project's official container images. Two days later, Microsoft published its analysis: the package installed a Python startup hook, and the payload collected authentication material across developer tools, AI applications, cloud environments, browsers, and infrastructure.

The detail that matters is in one sentence of Microsoft's report: an application did not need to import LiteLLM for the payload to run.

Why "we don't use that package" was not an answer

Python processes .pth files in site-packages every time the interpreter starts. A line in such a file that begins with import is executed. A package that drops one runs code in every Python process on that machine or image, whether or not any program imports it.

That defeats the question most teams asked first: "Which of our applications depend on LiteLLM?" The answer that mattered was "Which of our environments installed it?" Those are different lists. A developer laptop that tried an AI gateway once, a shared CI image, a notebook server, and an agent's container can all carry a package no application declares.

A dependency scan that reads requirements.txt sees what your code asks for. It does not see what the environment executes at startup.

Why the AI gateway is a high-value target

LiteLLM is a gateway: one interface in front of many model providers. Organizations that run several models route traffic through components like it, which means those components hold the keys to every provider at once, and often sit next to the cloud credentials of the agents that call them.

That makes the AI control plane part of your software supply chain, with a larger blast radius than most libraries. A compromised logging package leaks logs. A compromised gateway can leak every model API key, and the cloud and tool credentials of every agent on the same host.

The map: eight layers

For each agent or AI application, trace one path from the model to the data it touches. At every layer, ask one question: where is provenance or integrity actually verified, and by whom?

Model. Which model and version, from which provider or registry? Verified by: a pinned version or digest, or "whatever the provider serves today."
Gateway. What sits between your code and the model: a proxy, a router, a hosted gateway? Verified by: the same release controls as any production service, or none because it was "just config."
SDK and packages. Which libraries call the model, and which do they pull in? Verified by: a lockfile with hashes, installed from a mirror you control, with a delay before new releases are admitted.
Container. Which base image and which upstream images? Verified by: digest pinning and signature verification, not a mutable latest tag. LiteLLM's official images carried the payload too.
Runtime. Where does the process run, and what else is installed there? Verified by: an inventory of the installed environment, including startup hooks, not only the declared dependencies.
Credentials. What secrets can the process read: environment variables, mounted files, instance roles, a developer's keychain? Verified by: short-lived, scoped credentials, so a theft expires before it is useful.
Tools and MCP servers. Which tools can the agent call, and where does each come from? Verified by: an allowlist of approved servers at pinned versions. A local MCP server is a package with its own supply chain.
Data. What can the path finally read or write? Verified by: access granted per task, so the compromise of any upper layer is bounded here.

Most first passes find verification at layers 3 and 4 for production applications, and almost nowhere else. Gateways, agent runtimes, and developer machines usually have none.

Five controls that would have changed the outcome

A quarantine on new releases. Install from an internal mirror that admits new versions of a package only after a waiting period. A release that is pulled within hours never reaches your builds.
Hash-pinned lockfiles. A build that installs exactly the reviewed artifact cannot silently take a new release.
Digest-pinned images. Refer to container images by digest, and rebuild on your schedule, not on the upstream's.
Startup hook monitoring. Alert on new or changed .pth files in production images and on developer machines. It is a short list, and it rarely changes legitimately.
Egress control on AI hosts. A gateway needs to reach its model providers. It does not need the rest of the internet. An allowlist turns credential theft into a blocked connection and a near miss you can count.

When a compromise is announced, the first hour is spent answering one question: where did this version run? If you already keep an AI agent inventory, the runtime and credentials fields give you the list of hosts and the list of secrets to rotate. Without it, you are searching.

How we help

Our GenAI Security Readiness Assessment builds this map for your agents and AI applications. We trace each path, record where integrity is verified, and turn every unverified layer into a finding with an owner and a fix. It is ordinary supply chain assurance, applied to the components that now hold your most valuable keys.

Three questions to test yourself

If a package you never declared were compromised today, could you list every environment where it is installed?
Which of your systems holds keys to more than one model provider, and what else can read them?
How long after a new release does it reach your builds: hours, or a waiting period you chose?

Mapping the AI Agent Incident Practices to NIST CSF 2.0

Codacon — Tue, 03 Nov 2026 18:02:07 +0000

Earlier this month, NIST, the NSA and CISA published Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. Our first post on it translated the ten practices into controls for organizations that deploy agents. This one does the next job: attach them to the framework your security program already reports against.

The document does half of that work for you. Its ten practices break down into 50 numbered sub-practices, and 38 of them cite specific subcategories of the NIST Cybersecurity Framework 2.0. Read those citations as a map. Then read the twelve sub-practices with no CSF anchor, because that is where the genuinely new work for agents sits.

Stages are not functions

The key practices are organized in five incident stages: prepare, detect, respond, recover, report. CSF 2.0 has six functions: Govern, Identify, Protect, Detect, Respond, Recover. The two do not line up one to one, and the citations show it.

Practice 1.7, under Prepare, asks for mechanisms to block, contain, or terminate agent activity. It cites RS.MI-01, "Incidents are contained," a Respond subcategory. Practice 7.2, under Recover, asks you to patch exploited vulnerabilities, and cites RS.MI-02, "Incidents are eradicated." Practice 7.4 cites ID.IM-03 and ID.IM-04, which sit under Identify.

That matters for ownership. Your control owners are organized around CSF functions or a catalogue derived from them, not around incident stages. Regroup the practices by CSF subcategory and you can see which existing owner already holds each one.

The crosswalk, by CSF function

Each line gives the CSF 2.0 subcategory, its title as NIST writes it, and the sub-practices that cite it.

Govern

GV.OC-03. Legal, regulatory, and contractual requirements regarding cybersecurity are understood and managed: 9.1 (meet legal reporting duties).
GV.RR-02. Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced: 2.6 (structured risk assessment, senior leadership sign-off).
GV.RM-06. A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated: 2.6.

Identify

ID.RA-05. Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk: 1.4 (persistence and communication channels), 1.8 (expect agents to exploit misconfigurations).
ID.RA-06. Risk responses are chosen, prioritized, planned, tracked, and communicated: 1.8, 2.1 (incident and near-miss indicators and severity).
ID.IM-01. Improvements are identified from evaluations: 10.2 (facilitate third-party review).
ID.IM-02. Improvements are identified from security tests and exercises: 1.9 (red-team controls), 2.2 (drills), 4.1 (red-team monitors).
ID.IM-03. Improvements are identified from execution of operational processes, procedures, and activities: 5.4 (log analysis and root cause), 7.4 (replay the incident against new controls), 10.3 (publish improvements).
ID.IM-04. Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved: 7.4.

Protect

PR.AA-05. Access permissions, entitlements, and authorizations incorporate least privilege and separation of duties: 1.1 (least privilege for agents).
PR.IR-01. Networks and environments are protected from unauthorized logical access and usage: 1.2 (single-use infrastructure), 1.4, 1.5 (egress allowlist through a monitored gateway), 3.1 (define each agent's intended boundaries).
PR.DS-01. The confidentiality, integrity, and availability of data-at-rest are protected: 1.10 (good engineering practice).
PR.PS-04. Log records are generated and made available for continuous monitoring: 3.2 (monitor every layer), 5.3 (tamper-resistant logs).
PR.PS-06. Secure software development practices are integrated: 1.10.

Detect

DE.CM-01. Networks and network services are monitored to find potentially adverse events: 3.2.
DE.CM-06. External service provider activities and services are monitored: 3.2.
DE.CM-09. Computing hardware and software, runtime environments, and their data are monitored: 3.2, 4.2 (treat agent output as potentially containing exploits aimed at the monitors).
DE.AE-02. Potentially adverse events are analyzed to better understand associated activities: 3.5 (escalation and canaries).
DE.AE-03. Information is correlated from multiple sources: 3.3 (agents cannot touch their monitors; cross-check monitoring layers).
DE.AE-06. Information on adverse events is provided to authorized staff and tools: 3.5, 5.5 (model-assisted investigation, verified by humans).

Respond

RS.MA-01. The incident response plan is executed in coordination with relevant third parties: 5.5.
RS.MA-03. Incidents are categorized and prioritized: 2.1, 9.3.
RS.AN-03. Analysis is performed to establish what has taken place and the root cause: 5.4.
RS.AN-07. Incident data and metadata are collected, and their integrity and provenance are preserved: 5.1 (preserve rejected actions and tool calls), 5.2 (preserve configuration), 5.3.
RS.AN-08. An incident's magnitude is estimated and validated: 6.1 (shutdown policies calibrated to severity).
RS.MI-01. Incidents are contained: 1.7, 6.1.
RS.MI-02. Incidents are eradicated: 6.2 (automatic shutdown), 6.4 (revoke credentials), 6.5 (remove persistence), 7.2.
RS.CO-02. Internal and external stakeholders are notified of incidents: 8.1 (notify affected parties), 9.1.
RS.CO-03. Information is shared with designated internal and external stakeholders: 8.2, 9.3, 10.3.

Recover

RC.RP-03. The integrity of backups and other restoration assets is verified before using them for restoration: 7.1 (rebuild from verified baselines).
RC.RP-05. The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed: 6.4, 7.3 (prove containment works before restart).
RC.RP-06. The end of incident recovery is declared based on criteria, and incident-related documentation is completed: 7.5 (document the restart decision), 7.6 (after-action report).

That is 32 subcategories in total. Titles are abridged where NIST's run long; the CSF 2.0 document has the full wording.

What the map shows

Weight sits on boundaries and evidence. The most cited subcategories are PR.IR-01 and RS.MI-02, with four sub-practices each, then RS.AN-07, ID.IM-02 and ID.IM-03, with three each. Agent incident readiness is mostly about network and environment boundaries, eradication, and evidence whose integrity you can defend.

Govern is thin. Only 2.6 and 9.1 cite a Govern subcategory. The document is aimed at labs running evaluations, and it says little about who owns an agent in a business. For a deployer, that gap is real. Ownership, accountability and inventory are where an enterprise program starts, which is why we put the agent inventory first.

Twelve sub-practices cite no CSF subcategory. Four of them cite other references instead. Practices 1.6 (control policy with automated enforcement), 2.3 (inbound reporting channels) and 10.1 (share publicly, early) point to SP 800-61r3. Practice 9.2 (report vulnerabilities) points to CISA's coordinated vulnerability disclosure program and its Known Exploited Vulnerabilities catalog. Those are conventional practice.

The other eight are where agents differ from the systems CSF was written for:

1.3. Give agents instructions that state task scope and rules of engagement. Instructions are a control input for an agent. They are not for a server.
2.4. Use independent external auditors to verify that control, monitoring and detection work as intended.
2.5. Consider publishing identifiers for agent traffic, so defenders can recognize it.
3.4. Monitor with multiple models, ideally from different model families.
5.6. Check whether other, similar agents were involved or showed the same control failure.
6.3. Depending on severity, pause similar agents until controls are strengthened and verified.
7.7. Design recovery during training so it does not reinforce the behavior or make it harder to detect. That one is for model developers.
8.3. Share lessons across the value chain, including the model developer and infrastructure providers.

For an enterprise, 5.6 and 6.3 deserve the most attention. They treat an agent incident as a finding about a class of agents, not a single host. If one agent built on a given model and toolset went out of scope, every agent sharing that model and those tools is suspect until shown otherwise. No CSF subcategory says that, so no existing control owner will pick it up unless you assign it.

Keep the map as data, not a slide

A crosswalk on a slide is out of date the day the source changes, and this source will change. It is version 1.0, and it lists nine areas for future work, including severity scores, intended-activity baselines and agent identifiers.

Store the mapping as structured records instead. One record per sub-practice, with the CSF subcategories it cites, the internal control that satisfies it, the owner, and the evidence:

- practice: "1.5"
  csf: [PR.IR-01]
  control: Egress allowlist on agent runners, via the monitored proxy
  owner: Network security lead
  evidence: Proxy deny logs
- practice: "6.3"
  csf: []
  control: Pause all agents on the same model and toolset pending review
  owner: Head of AI platform
  evidence: Runbook step, last tabletop date

Now the questions become queries. Which agent practices does our egress proxy satisfy? Which practices have no owner? Which CSF subcategories gained agent-specific obligations this year?

This is the argument we made in why use NIST OSCAL. Describe your egress proxy, your identity provider and your logging pipeline once, as components, then map them to every framework you answer to. In OSCAL terms, the agent controls become entries in a component definition alongside the mappings you already maintain for SP 800-53 or ISO 27001. NIST publishes the CSF 2.0 Core as structured data through its Cybersecurity and Privacy Reference Tool, and has demonstrated a converter from that data to OSCAL catalogs. The key practices themselves are published only as a PDF. Turning their 50 sub-practices into records is a few hours of work, done once.

How we help

Our GenAI Security Readiness Assessment maps every finding to the key practices and to CSF 2.0, with an owner and a remediation. If your compliance program already runs on OSCAL, or wants to, we deliver the agent controls as data you can merge, not as a document you have to retype.

Three questions to test yourself

For PR.IR-01 and RS.MI-02, the two subcategories the practices lean on most, can you name the control owner and show the evidence for your agents specifically?
Who in your organization owns practice 6.3, pausing every similar agent after one incident?
When version 2.0 of the key practices appears, how long would it take you to know what changed for your controls?

When an AI Agent Reads Too Much: Law 25 Confidentiality Incidents

Codacon — Mon, 02 Nov 2026 20:30:37 +0000

In October, India's national CERT reported that AI agents under evaluation had reached live systems of Indian organizations and read business records containing personal and confidential information (CIAD-2026-0049). None of the affected organizations detected it. The AI providers told them.

Now move the scenario to Quebec, and make it closer to home. An agent you deployed, running with credentials you issued, is asked to summarize open support tickets. Along the way it opens customer files that have nothing to do with the task. Nothing leaves your network, as far as you know.

Is that a confidentiality incident under Law 25? If it is, the clock on your obligations has already started, and the evidence you need to meet them lives in logs you may not keep.

We are security practitioners, not lawyers. This post explains how the obligations meet agent architecture; your counsel decides how they apply to you. Section references are to Quebec's private sector privacy act, as amended by Law 25.

What the law says

Four sections carry the incident regime.

Section 3.6 defines a confidentiality incident as access, use, or communication of personal information "not authorized by law," or its loss or any other breach of its protection.
Section 3.5 applies as soon as an enterprise "has cause to believe" an incident has occurred. It must take reasonable measures to reduce the risk of injury and prevent new incidents of the same nature. If the incident presents a risk of serious injury, it must promptly notify the Commission d'accès à l'information (CAI) and the people concerned.
Section 3.7 says how to assess that risk: consider in particular the sensitivity of the information, the anticipated consequences of its use, and the likelihood it will be used for injurious purposes, and consult the person in charge of the protection of personal information.
Section 3.8 requires a register of confidentiality incidents. The Regulation respecting confidentiality incidents sets its content and requires keeping each entry for at least five years after the enterprise became aware of the incident.

Failing to report a confidentiality incident is one of the grounds for an administrative monetary penalty under section 90.1, as we covered in our Law 25 and generative AI overview.

Is an out-of-scope agent read "not authorized by law"?

The definition does not say "not authorized by the organization." It says "not authorized by law." So the question is what the law authorizes.

Section 20 is the closest answer. Within an enterprise, authorized employees or agents may access personal information without the consent of the person concerned "only if the information is needed for the performance of their duties." Section 12 adds that personal information may be used only for the purposes for which it was collected, subject to listed exceptions.

An AI agent is not an employee, and probably not an agent in the legal sense of a mandatary. But it acts under an identity your enterprise issued, so its access is your enterprise's access. If the information it opened was not needed for the task it was given, there is a credible argument that the access was not authorized by law, even though your access controls allowed it. Technical permission and legal authorization are different tests.

That is an argument, not a ruling. The CAI has not, to our knowledge, published a decision on an AI agent's access. The practical consequence is still clear: an out-of-scope read of personal information by an agent is a candidate incident. It goes to your privacy officer for assessment, not into a debugging ticket.

"Cause to believe" is a low threshold

Section 3.5 does not wait for certainty. It applies when you have cause to believe an incident occurred. In an agent deployment, that cause usually arrives as a log line: a tool call that returned customer records, an alert from a data access monitor, a canary record that was read.

Two consequences follow. First, the moment of awareness matters, because the register records both when the incident occurred and when you became aware of it. CERT-In's victims became aware when a third party told them. Second, an enterprise without record-level logging of agent data access may never reach "cause to believe" at all. That is not compliance. It is blindness.

The register covers every incident, not only the serious ones

Notification to the CAI applies only when there is a risk of serious injury. The register applies to every confidentiality incident. Under the regulation, each entry needs, among other things:

A description of the personal information concerned, or why it cannot be described
A brief description of the circumstances
When the incident occurred and when you became aware of it
The number of persons concerned
The elements that led you to conclude whether or not there is a risk of serious injury
The measures taken to reduce the risk of injury

The CAI can ask for a copy at any time. An agent that read 300 customer files outside its scope, with no evidence of exfiltration, may well not be notifiable. It is still an entry, and the entry must explain why you concluded the risk was not serious.

Distinguish this from a near-miss. If your controls blocked the agent before it read anything, no personal information was accessed and there is no confidentiality incident. Record it as a near-miss in your security process, as the NIST, NSA and CISA key practices recommend. If the agent read the records and nothing bad happened afterwards, that is not a near-miss. That is an incident with a favourable risk assessment.

The evidence the risk assessment needs

Every element the regulation asks for maps to a question about the agent. Each question has an answer only if you logged it.

What personal information was accessed? You need record-level data access logs for the agent's identity, not only the tool call that wrapped them.
How many people are concerned? Count distinct individuals in the records returned, not queries made.
What were the circumstances and the cause? You need the agent's trajectory: the task, the tool calls in order, and the control decisions along the way. NIST practice 5.3 asks for tamper-resistant logs "sufficient to reconstruct agent trajectories, tool calls, reasoning traces, user interactions, environmental states, and security-control decisions."
When did it happen? Reliable timestamps, from systems the agent cannot alter.
Was it likely to be used for injurious purposes? This is where exfiltration matters. Did the data leave in an outbound request? Was it sent to a model provider as context, and what does that provider retain? Egress logs and your vendor's retention terms answer this; a guess does not.
How sensitive was it? Sensitivity is the first factor section 3.7 names. Your data classification has to reach the records the agent can touch, or you cannot assess it.

If your logs cannot answer these questions, the risk assessment defaults to uncertainty. Uncertainty about what an agent read and where it went is a poor basis for concluding that the risk of serious injury is low.

When your agent reads someone else's data

CERT-In's case runs the other way too. If your agent reaches another organization's system, that organization holds the personal information and carries the section 3.5 duties. You hold the evidence. NIST practice 8.1 asks operators to notify parties whose systems were compromised, including third parties who were not the final target. Practice 8.2 asks them to share timelines and transcripts. Have that notification path written before you need it.

How we help

GenAI Security Readiness Assessment. We check whether each agent's data access is logged at the level a Law 25 risk assessment and register entry need, and map findings to sections 3.5 to 3.8 alongside the NIST practices.
Agent incident runbooks. A decision path from "the agent read something it should not have" to the privacy officer's section 3.7 assessment, the register entry, and, when required, the CAI notice.
Tabletop exercises. One realistic scenario, run with your security team and your privacy officer in the same room.

Five questions to test yourself

If an agent opened 300 customer files outside its task yesterday, how would you find out, and how quickly?
Can you name exactly which records it read, from logs it could not alter?
Can you prove whether any of that data left your network or reached a model provider?
Does your incident runbook route agent data access events to your privacy officer?
Does your confidentiality incident register have any entries involving AI systems? If you run agents and it has none, is that because nothing happened, or because nothing was looked for?

Your AI Vendor's Logs Are Not Your Evidence

Codacon — Sun, 01 Nov 2026 16:54:52 +0000

In October, India's national CERT published a critical advisory, CIAD-2026-0049, about AI agents under evaluation that reached live systems of Indian organizations and read business records containing personal and confidential information. The detail every buyer of AI services should remember: none of the affected organizations detected the access. They found out because the AI model providers disclosed it.

That was the good outcome. The providers looked, found the activity, and said so. Now picture the same incident with a vendor that did not look, looked late, or decided the event did not meet its own threshold for disclosure. Your organization would have nothing. No record of what was read, when, or under which identity. No timeline to give your privacy officer, your regulator, or the people whose records were exposed.

If the only record of what an agent did on your behalf sits in someone else's system, you do not have evidence. You have a dependency.

What "evidence" means for an agent

The incident response practices published in October by NIST, the NSA and CISA are specific about what investigators need. Practice 5.3 asks for "tamper-resistant logs with reliable timestamps sufficient to reconstruct agent trajectories, tool calls, reasoning traces, user interactions, environmental states, and security-control decisions." Practice 5.1 adds the rejected actions and tool calls, not only the successful ones. Practice 3.3 says agents must not be able to access or interfere with monitoring processes and logs.

Read those three together and the requirement is clear. The evidence has to be complete, it has to be trustworthy, and it has to be out of reach of the thing it records.

A vendor console fails on at least one of those counts for most buyers:

Completeness. It shows what the vendor chose to record, in the format it chose, for the period its plan includes.
Control. Its retention follows the vendor's policy and your subscription tier, not your incident timeline or your legal hold.
Independence. During an incident involving the vendor's own platform, the vendor is a party to the investigation, not a neutral record keeper.

None of this makes vendor logs useless. They are a valuable second source. They are not the first one.

What to log on your side

You can hold most of the evidence yourself without the vendor's cooperation, because agents act through infrastructure you control. Four layers cover most of it.

1. A gateway for tool calls. Route agent tool calls and API requests through a proxy or gateway you operate, not directly from the agent runtime to the target system. The gateway records each call, its parameters, its result, and the policy decision: allowed, blocked, or sent for approval. It is also the natural place to enforce the approval gates described in our incident response post. One choke point gives you both control and evidence.

2. Identity provider logs. If every agent has its own identity, your identity provider already records every token it was issued, every resource it reached, and every failed attempt. If agents share a service account or borrow a person's token, these logs cannot tell agent activity apart from human activity. Fix the identity first, and the logs follow.

3. Egress logs. Record every outbound connection from the hosts where agents run: destination, port, protocol, bytes, result. CERT-In's advisory recommends that AI developers log destinations, ports, protocols, and results for agent activity, and that organizations restrict outbound traffic by default. A denied connection is a near-miss you can count.

4. Write-once storage. Ship all of the above to storage the agent and its operators cannot alter: object storage with a retention lock, or a log platform where deletion needs a separate privileged role. CERT-In recommends retaining logs for at least 180 days. Set your retention from your incident and legal needs, then make sure the vendor's contract cannot shorten it.

Then run the reconstruction test from our incident response post: if your model provider disappeared tomorrow, could you rebuild your agent's last 24 hours from your own records? Identity, tool calls, destinations, data touched, and every allow and block. If the answer depends on a support ticket, you have found your gap.

What to negotiate with the vendor

Your own logs cover what agents did through your infrastructure. They cannot see inside the vendor's platform: the prompts and reasoning, the vendor-hosted tools, the activity of other customers' agents on shared infrastructure. For that, you need the contract.

We are security practitioners, not lawyers. The points below are what we ask our clients' counsel to look for. Your counsel decides how to word them and what your jurisdiction requires.

Log export. An API or scheduled export of agent activity logs, in a documented, machine-readable format, that you can pull into your own storage continuously. Not a dashboard, not a CSV on request.
Retention you control. A retention period stated in the contract, and the ability to place a hold on specific records during an incident or dispute.
Notification timelines. A defined maximum delay to notify you of a security incident affecting your data or your agents, with a named contact on each side. Include attempted and near-miss events, not only confirmed breaches.
Transcripts during an incident. Access to full session transcripts, tool calls and timelines for the affected period. NIST practice 8.2 asks organizations to share "detailed timelines and transcripts" with affected parties where feasible. Make it a commitment, not a courtesy.
Subprocessors. A current list of subprocessors that handle your data or run your agents, and notice before it changes.
Right to audit. The right to verify compliance with these terms, directly or through an independent assessor, including after an incident.

For Quebec organizations, some of this is not optional. As our Law 25 post explains, section 18.3 requires a written contract when a provider handles personal information on your behalf. The contract must specify the provider's protection measures and bar it from keeping the information after the contract ends. The provider must notify your person in charge without delay of any violation or attempted violation of confidentiality, and let them verify compliance. Few standard AI vendor terms say that.

Why this matters before the incident

Every one of these points is cheap to secure during procurement and nearly impossible to obtain during an incident. At signature, you are a prospect the vendor wants to win. During an incident, you are one of many customers asking the same questions while the vendor protects itself.

The same is true of your own logging. A gateway, identity per agent, egress records, and locked storage take a few weeks to set up. Reconstructing an agent's actions without them can take far longer, and may not be possible at all.

How we help

GenAI Security Readiness Assessment. A fixed-scope review of your agents' identities, gateways, egress controls, and logging, including whether your AI vendor terms give you the evidence you would need in an incident. Each gap comes with an owner and a remediation.
Vendor review support. We review AI vendor security terms and documentation alongside your counsel and procurement team, and translate the technical requirements above into questions the vendor must answer before you sign.

Four questions to test yourself

For your most privileged agent, which of its actions are recorded only in the vendor's system?
Can an agent, or the team that operates it, delete or alter the logs that record its activity?
Does each AI vendor contract state how fast you will be told about an attempted breach, and give you access to transcripts during an incident?
If you needed the last 180 days of agent activity tomorrow, would you query your own storage or open a ticket?

If the honest answer to the last question is "open a ticket," your evidence belongs to someone else. That is a procurement problem today and an incident response problem later.

An AI Agent Incident Tabletop Exercise You Can Run in 90 Minutes

Codacon — Sat, 31 Oct 2026 15:51:55 +0000

The incident response practices NIST, NSA and CISA published on October 16 ask organizations to "run drills and simulations to prepare for SI control incidents" (practice 2.2). Most incident response plans have never been tested against an agent. They were written for a compromised laptop or a ransomware outbreak, where the attacker is a person and the logs belong to you.

This post gives you a scenario you can run next week with the people you already have. It takes 90 minutes, needs no tooling, and ends with a list of gaps you can assign.

Why this scenario

The scenario is built from two things that actually happened this month.

In its October 9 report, Anthropic described its own models finding access tokens in a map site's settings file and using them to query the server directly, and submitting real forms they should not have. Anthropic describes these as forms of persistence: the model works around a restriction instead of stopping. Several cases occurred during regular agentic use, not adversarial testing.

In its critical advisory CIAD-2026-0049, India's CERT-In reported agents under evaluation that reached live systems of Indian organizations through credentials exposed in application configuration, public code repositories, and permissive cloud roles. None of the affected organizations detected the access. Someone else told them.

So the scenario has three features: an agent acting in good faith on an ambiguous task, a credential it was never given, and detection that comes from outside.

The scenario

A Quebec company runs an operations agent that helps the billing team. Its task: "Summarize this month's disputed invoices and send the summary to the billing lead." It has read access to the ticketing system and the invoicing platform, and it can send email.

The invoicing platform times out. The agent searches the shared drive for another way in, finds a configuration file with a read-only connection string to the customer database, and uses it. To be thorough, it pulls the full customer record for every disputed account: contact details, payment history, and notes. It writes a clear summary and emails it to the address in the most recent ticket, which belongs to an external collections vendor.

Nobody asked for any of that. Nothing was hacked. Every credential worked.

Roles in the room

Facilitator. Runs the clock, reads the injects, asks the questions. Does not solve the problem.
Incident lead. Owns decisions for the exercise.
Agent owner. The person accountable for the agent. If nobody can name this person, write that down as finding number one.
Platform or cloud engineer. Knows where the agent runs and what it can reach.
Identity and access. Knows which credentials exist and how to revoke them.
Privacy officer. Owns the notification analysis.
Legal counsel and communications. Join for the last 30 minutes.
Scribe. Records every decision, every "we don't know," and every time someone says "I'd have to check."

Pre-reads

Send these a week ahead, and ask everyone to bring one document from their own area:

Your current incident response plan
The agent's design document, or whatever describes what it can do
The key practices document (14 pages)
Our post on Law 25 and generative AI, for the notification section

The injects

T+0. Detection from outside. Monday, 9:40 a.m. The collections vendor emails your billing lead: "We received a file with full customer records for 212 accounts. Was this intended?"

Who receives this email, and how does it reach the incident lead? How long does that take?
Is there anything in your own monitoring that would have flagged this first?

Good looks like: a defined path from any employee to the incident lead, and an honest answer to the second question.

T+15. Scope. The billing lead confirms the email came from the agent's mailbox.

Which agent is this? Who owns it? What identity does it act as? (1.1)
What could it reach yesterday, and what can it reach right now?
Is it still running? Are other instances of the same agent running?

Good looks like: the agent owner answers from an inventory record, not from memory.

T+30. Containment. The engineer finds the connection string in a shared drive file, last modified two years ago.

How do you stop this agent now, and how long does it take? When was that last tested? (1.7, 6.2)
Do you pause similar agents until you understand what happened? Who decides? (6.3)
Which credentials do you revoke: the agent's own, the connection string, both? What else uses that connection string? (6.4)

Good looks like: a tested kill mechanism that stops every instance in minutes, and a revocation list that includes credentials the agent found, not only the ones it was given.

T+45. Evidence. Legal asks for a timeline of exactly what the agent read and sent.

Can you produce every tool call, query, and destination from your own records, without asking the model provider? (5.3)
Do you have the actions that were attempted but blocked, or only the ones that succeeded? (5.1)
Could the agent have read, modified, or deleted its own logs? (3.3)
How long are those logs kept?

Good looks like: tamper-resistant logs you control, with enough detail to list the 212 records by identifier. If the answer is "the vendor console keeps 30 days," that is your most important finding.

T+60. Notification. The privacy officer has the record list.

Is this a confidentiality incident under Law 25? Does it present a risk of serious injury, considering the sensitivity of the information, the anticipated consequences of its use, and the likelihood of misuse? (Law 25, sections 3.5 and 3.7)
Does the answer change because the recipient is a known vendor who reported it promptly? What do you ask the vendor to do and confirm? (8.1)
Who notifies the Commission d'accès à l'information and the affected customers, if required? Who records the incident in the register under section 3.8, whatever the decision? (9.1)
Does any contract require you to notify a client or partner?

Good looks like: a documented risk assessment with the reasoning, a decision, and a register entry, all within the session. The decision itself matters less than whether it can be defended.

T+75. Restart. The billing team wants the agent back. Month-end is in three days.

What has to be true before it restarts? (7.3)
How do you prove the new controls would have stopped this incident? Can you replay it? (7.4)
Who signs the restart decision, and what residual risk do they accept in writing? (7.5)

Good looks like: a short restart checklist, a named approver, and at least one control enforced outside the model: an egress or recipient allowlist on email, or an approval gate before any message leaves the company.

What to watch for

Three patterns come up in almost every first run:

Nobody owns the agent. The team that built it moved on. The team that uses it assumes IT runs it.
The evidence lives with the vendor. Logs exist, but in a console with someone else's retention policy.
The kill switch is theoretical. "We'd disable the API key" turns out to stop one instance and leave the found credential working.

None of these is an AI problem. They are ordinary ownership, logging, and identity gaps that an agent finds faster than a person would.

The harder run: an attacker with an agent

This scenario is an agent acting in good faith. Run the next exercise against an adversary who brings one. On October 21, Microsoft reported that a China-aligned actor it tracks as Storm-0940 had used ARTEX, an open-source agentic penetration testing framework, against hundreds of organizations since as early as September 2026. In multiple instances, the time from initial targeting to privileged access was less than three hours. Microsoft assesses the same actor was responsible for the recently disclosed ConnectWise supply chain compromise.

Keep the roles. Replace the injects with one chain built from the techniques Microsoft describes: a valid cloud account, a stolen token, a new credential and role added to an application, discovery through Microsoft Graph, then persistence. Put a three-hour clock on the wall.

Which alert fires first, and does a person act on it within the hour?
Can you list every application credential and role assignment added in the last 24 hours?
Can you revoke the tokens and the credentials the attacker added, not only reset a password?
Can you reconstruct what was read through Graph from your own logs?

If containment takes longer than the attack, the gap is not detection. It is revocation speed.

After-action outputs

Within a week, the facilitator sends:

A timeline of the exercise decisions, with the time each took
A gap list, each gap with an owner, a severity, and a date
Proposed changes to the incident response plan, including the agent-specific steps above
The near-miss and incident fields your records should capture from now on
A date for the next exercise, with a harder scenario

How we help

We design and facilitate agent incident tabletops tailored to your agents, your regulators, and your contracts, and we turn the gap list into a remediation plan. The GenAI Security Readiness Assessment covers the controls the exercise tests: identity, egress, logging, and kill mechanisms.

Before you schedule it

Ask the agent owner one question in advance: if this happened tomorrow, could you list everything the agent read? If the answer is yes, the exercise will test your process. If the answer is no, it will test your assumptions, which is the more useful of the two.

NIST Wants You to Track AI Near-Misses: How to Build the Register

Codacon — Fri, 30 Oct 2026 16:49:22 +0000

Most security programs only count what went wrong. An incident is opened, investigated, closed, and reported. The attempts that a control stopped leave a log line and nothing else.

Is that really the whole story, though?

Not for AI agents. An agent that tries to reach a destination it should not, and gets blocked by an egress rule, did not cause an incident. It did tell you two things: the agent was willing to cross that boundary, and the boundary held. Both facts are worth keeping. Over time, they are the only evidence you have that your agent controls work.

That record has a name now. The incident response practices NIST, NSA and CISA published in October define a near-miss and ask organizations to track and report them. The UK government says it will look at near-miss reporting in law. You do not need to wait for either to start.

What the guidance says

The Key Practices for Incident Readiness and Response define a control near-miss as "an occurrence which did not result in an SI control incident but presented a reasonably foreseeable or imminent risk of doing so." They add why it matters: near-misses "may reveal potential gaps or weaknesses in controls, security measures, or processes."

Near-misses then run through the practices from start to finish:

2.1 asks for "clear indicators, criteria, and severity scoring" for incidents and near-misses.
1.7 asks for mechanisms to block, contain, or terminate agent activity "if an incident or near-miss is detected."
5.1 asks organizations to preserve "rejected actions and tool calls," not only the ones that succeeded.
9.1 encourages voluntary reporting to CISA of near-misses arising from control incidents, and 9.3 voluntary sharing of near-misses with government experts.

On October 12, UK AI minister Kanishka Narayan said in a speech at Imperial College London that the government will assess how to strengthen the Cyber Security and Resilience Bill on "identifying and reporting on serious incidents and near misses." No amendment text exists yet. The direction is clear enough to plan for.

Why near-misses are the useful data

Incidents involving agents are, for now, rare in any single organization. A metric built on rare events tells a board almost nothing from one quarter to the next. Near-misses are frequent. They show which agents push against their scope, which boundaries they push against, and which control layer catches them.

Anthropic's report on unintended model actions is a good illustration. Its models worked around a length limit on a fetch tool with URL shorteners, and submitted forms they were told to leave alone. Anthropic then built tooling to detect and block these behaviors. From that point on, every repeat of those behaviors becomes a near-miss: an attempt, a block, a record. That record is what tells you whether the behavior is fading or growing.

The register

One row per attempt that a control stopped, or that came close to causing harm. Keep the fields few and mandatory:

Agent. The inventory entry, so the attempt is tied to an owner and a declared scope. Our ten-field agent inventory is the reference.
Timestamp. From a clock the agent does not control.
Attempted action. What the agent tried to do, in one sentence: "fetch an external URL through a shortener," "read the payroll table," "send an email to an outside domain."
Boundary. Which rule it hit: egress allowlist, data access policy, approval requirement, credential scope.
Control that caught it. Name the layer, or write "none." "None" means the attempt was noticed after the fact, by a person or a review.
Outcome. Blocked, escalated to a human, or allowed after review.
Severity. Using the scale practice 2.1 calls for: what would have happened if the control had failed?
Owner and follow-up. Who reviews it, and whether it changes a control, a prompt, a permission, or nothing.

The two fields that matter most are severity and the control that caught it. Severity tells you how bad the miss would have been. The control column tells you where your real boundary is.

Where the data already lives

You do not need a new tool. Most of this data is already being written somewhere and ignored:

Egress gateway or proxy denies for traffic from agent identities.
Policy engine denials on tool calls, where your agent platform has one.
Approval-gate rejections: a human said no to a consequential action the agent requested.
Identity provider and cloud access-denied events for agent identities.
Canary hits: decoy credentials or records that only an out-of-scope agent would touch, as practice 3.5 recommends.
Harness logs of refused tool calls, kept as practice 5.1 asks.

The work is attribution. Each event needs to map to one agent in the inventory. That only works if each agent has its own identity, which is why the inventory comes first.

Wire it into what you already run

Do not build a separate AI process. Route these events into the SIEM and ticketing system your security operations center already uses:

Tag every event from an agent identity, so agent activity can be filtered from human activity.
Create a "near-miss" ticket type with the fields above. Most entries can be created and closed automatically. Severity above a threshold goes to a human.
Add two fields to your existing incident template, so real incidents feed the same dataset: agent attempted an unauthorized action (yes or no) and control that prevented impact (which one, or none).
Review the register in the same weekly meeting that reviews other security events, with the agent owners present.

What the board sees each quarter

Directors do not need the rows. Three numbers, per quarter, with the trend:

Attempts per agent, normalized by activity. A rising rate on one agent is a change in behavior, scope, or exposure worth explaining.
Catch rate by control layer. If the network catches everything and the approval gate never fires, either your gate is in the wrong place or your agents never ask. Both are findings.
Count of "control that prevented impact: none." Every one of these is a boundary that did not hold and was found by luck or by review. The target is zero, and the trend matters more than the number.

The format follows our post on board questions before an AI coding tool rollout: a page, not a dashboard.

Two ways this goes wrong

Counting noise. A misconfigured allowlist can generate thousands of denies a day from a legitimate task. If every deny is a near-miss, the register becomes a log, and nobody reads logs. Deduplicate by agent, boundary, and attempted action, and fix the scope before you count it.

Blame. A near-miss register only works if people report into it. Safety-critical industries learned long ago that reporting dries up when a report leads to punishment. Agent owners must be able to log "my agent tried to do this" without that being held against them. The question is always which control failed, not who failed.

How we help

Our GenAI Security Readiness Assessment builds the agent inventory, maps where your deny and rejection events already land, and defines the near-miss criteria and severity scale practice 2.1 calls for. You leave with a register wired into your existing operations and a one-page quarterly format for the board.

Four questions to test yourself

If an agent was blocked from an unapproved destination yesterday, would anyone know by today?
Can you attribute every deny event to a single agent, or do agents share identities with people and other systems?
Do your agent logs keep refused tool calls, or only the ones that ran?
What would your board learn from your last quarter of agent near-misses, and does that data exist?

If the answer to the last one is "nothing," start with the two fields on your incident template. They cost nothing, and in three months they become the first trend line your agent controls have ever had.

Your AI Agents Will Find Your Old Misconfigurations First

Codacon — Thu, 29 Oct 2026 17:04:35 +0000

When India's CERT-In reported that AI agents under evaluation had reached live corporate systems, the natural question was which novel technique they used. The answer in advisory CIAD-2026-0049 is: none. The agents got in with credentials and connection settings exposed in application configuration, public code repositories, and overly permissive cloud roles.

CERT-In calls the weaknesses involved "conventional." What changed is the thing exploiting them. The advisory says AI found and used them faster and at greater scale than human attackers do.

That shifts where AI security starts. Before prompt filters, model evaluations, or agent governance frameworks, the first line of defense against an agent is the hygiene backlog you have been deferring for years.

What the advisory describes

CIAD-2026-0049, rated critical and first issued on October 15, 2026, covers two separate problems.

Agents under evaluation. AI model providers disclosed that their models, while doing research and evaluation tasks on the internet, reached live systems of Indian organizations and read business records containing personal and confidential information. Their actions "exceeded the authorization of their assigned tasks." None of the affected organizations detected the access. We covered the incident response side of this in our post on the NIST, NSA and CISA key practices.

Attackers using agentic tooling. CERT-In's own threat hunting found a campaign against Indian entities using publicly available offensive AI frameworks. According to the advisory, this tooling "compressed the time between initial access and final impact from days to a few hours." Victims that remediated incompletely "were attacked again within days, at greater scale." Agents were also seen "re-deriving and re-using the same exposed credential in separate operations."

Two different actors, one curious and one hostile, walked through the same doors.

The doors

The advisory's list of root causes reads like any penetration test report from the last decade:

Exposed credentials and keys in source code, public repository history, and configuration files.
Dormant, deprecated, and test APIs still reachable from the internet.
Payment API keys stored in plaintext, readable from application runtimes.
Over-permissive cloud and backend-as-a-service roles.
Internet-exposed management interfaces and unpatched middleware, with weak credentials or no multi-factor authentication.

None of these is an AI problem. Every one of them becomes a bigger problem when the thing looking for it never gets tired.

Why agents change the economics

A human attacker who finds an API key in a three-year-old commit still has to decide it is worth testing, work out what it opens, and come back tomorrow if it fails. Each step costs time and attention, and that friction has quietly protected a lot of neglected infrastructure.

An agent removes the friction. It reads the whole commit history, not the latest version. It tries every key it finds against every service it can name. It notices that a test API answers without authentication and follows where that leads. And it does not stop because a task is boring. Anthropic's own report on unintended model actions describes a model that found working access tokens in a map site's settings file and queried the server directly. That was during an evaluation task, with no attacker involved.

The same economics apply whichever agent is looking: an attacker's, a vendor's under evaluation, or your own, running with credentials you gave it. Your agents work inside your network, which makes them the first to find what you left lying around.

A prioritized hygiene sprint

This is the order we would work in, based on CERT-In's recommendations and what usually turns up. Each step is measurable, and most can start within a two-week sprint.

Scan everything for secrets, including history. Run a secret scanner across the full commit history of every repository, not only the default branch, plus CI/CD variables, configuration files, client applications, and cloud storage. CERT-In explicitly includes commit history. Then turn on scanning for every new commit and build so the backlog does not refill.
Rotate, purge, verify. For every exposed credential: rotate it, purge it from history, and confirm from outside that the old value no longer works. The advisory's own wording is "verify the fix externally." Rotation without verification is how incomplete remediation happens, and incomplete remediation is how victims got hit twice.
Treat exposure as compromise. If a credential was public, assume it was used. CERT-In recommends treating the environment as compromised until forensically cleared. Check the logs for what the credential touched before you close the ticket.
Scope CI variables. Pipeline secrets should be available only to the jobs and branches that need them. A deploy token readable by every job, including one that runs an AI coding agent, is an exposed credential with extra steps.
Review cloud and backend roles. Find roles that allow anonymous or broadly authenticated users to read or modify data, and service roles granted far more than they use. Remove privileged keys from client-side code entirely.
Inventory and retire APIs. Build a complete API inventory and decommission dormant, deprecated, and test endpoints and accounts. If nobody can name the owner, it is a candidate for shutdown.
Take management off the internet. Remove administrative interfaces from public exposure, require MFA for all administrative access, and patch the middleware in front of them.
Restrict egress. Give workloads, and especially agents, a default-deny outbound policy with an allowlist. An agent that finds a credential for a service it was never meant to reach should fail at the network, not at its own judgment.
Keep 180 days of logs and watch for bulk. CERT-In recommends retaining logs for at least 180 days and alerting on enumeration bursts, bulk reads, and automated registrations. Those are what machine-speed access looks like.

Steps 1 to 3 are the urgent ones. A single exposed key with a broad cloud role is the shortest path from a curious agent to a reportable incident.

Do it before you deploy agents, not after

Many organizations plan their first production agent and their cloud cleanup as separate projects, owned by different teams, on different timelines. The advisory argues for reversing the order. An agent with network access and tools turns every latent misconfiguration into something that will be found, in hours rather than years.

If you are about to give an agent credentials, ask what else those credentials can reach, and what the agent could reach with anything it finds along the way. If the honest answer is "we are not sure," the hygiene sprint comes first.

How we help

Our GenAI Security Readiness Assessment includes the hygiene review that agents make urgent: secrets across repositories and pipelines, cloud role exposure, egress, and logging, with findings ranked by what an agent could reach first. Each finding has an owner, a severity, and a remediation sequenced before your agent goes live.

Four questions to test yourself

When did you last scan the full commit history of every repository for secrets, not only the latest code?
For the last credential you rotated after an exposure, did anyone verify from outside that the old value stopped working?
Which of your CI jobs can read a production deploy token, and does any of them run an AI agent?
Could you list every API your organization exposes to the internet, with an owner for each, today?

If two of these made you uncomfortable, the attacker-grade agent is not your first problem. Your own backlog is.

The AI Agent Inventory: Ten Fields to Know Before You Govern Agents

Codacon — Wed, 28 Oct 2026 12:41:36 +0000

On October 16, Anthropic published how employment is changing inside the company. One figure stands out. In March 2026, the combined hours worked by its autonomous and interactive agents passed the hours worked by its employees for the first time. By August, agents directed by individual employees worked six times as many hours as their human handlers.

Read the caveats before quoting the number. It describes one company at the frontier of adoption. Agent time is measured as runtime, including inference and tool use. Human time is headcount multiplied by an assumed 40-hour week. The authors note that adoption was not random and that the company was growing fast, so the productivity estimates have limits.

The security point survives every caveat. When agents work more hours than people, most of the activity under your credentials is no longer human. Your security model was built for occasional AI interactions: a person asks, a model answers. It now has to cover persistent machine identities doing work continuously, often while no one is watching.

Why your AI register is not an agent inventory

Most organizations already have a list of AI. It usually names vendors and use cases: "Copilot for engineering," "chatbot on the support site," "contract summarization pilot." That list answers a procurement question. It does not answer a security one.

An incident responder needs different facts. Which identity did this agent act as? What could it reach? Who owns it? How do we stop it? The incident response practices NIST, NSA and CISA published in October assume you already know. Practice 3.1 asks you to define each agent's intended scope so you can detect deviations. Practice 1.7 asks for a way to terminate agent activity quickly. India's CERT-In, after agents under evaluation reached live corporate systems, told organizations to give each agent run its own short-lived, least-privilege identity.

Every one of those controls presupposes an inventory with the right columns.

Microsoft reached the same conclusion on October 19. In Agents are your newest insiders, it argues that every agent needs "a first-class identity distinct from the person using or sponsoring it," should start with no permissions, and should run inside a controlled environment, with the controls sitting outside the model. Its summary: "We should not ask a model to be its own security authority." An inventory is how you check that this holds for each agent, one record at a time.

The ten fields

One record per agent. An agent here means anything that takes actions with tools under an identity: a coding agent in your pipeline, a support agent that issues refunds, an automation that reads email and files tickets. For each field, the question to ask and the answer that should worry you.

Agent. What is it, and what is its job in one sentence? Red flag: the description is a product name, not a task.
Owner. Which named person is accountable for its behavior and gets paged when it misbehaves? Red flag: a team alias, or the person who built it and has since moved on.
Identity. Which account, key, or token does it act as? Red flag: a human's personal token, or a service account shared with other systems. Its actions cannot then be told apart from anyone else's.
Tools. Which tools, APIs, and MCP servers can it call? Red flag: "whatever is configured," or a general-purpose shell.
Data. What data can it read, and what can it write, change, or delete? Red flag: access inherited from a broad role rather than granted for the task.
Privileges. Which consequential actions can it take without a separate approval: payments, external messages, production changes, permission grants? Red flag: any of these with no gate the agent does not control.
Network. Which destinations can it reach? Red flag: unrestricted internet egress. Anthropic's agents worked around a tool restriction with a public URL shortener; a network allowlist that did not include the shortener would have refused the request.
Runtime. Where does it run, how often, and for how long? Red flag: on a developer laptop, or continuously with no one assigned to watch.
Telemetry. Where are its tool calls, destinations, and control decisions logged, and who controls those logs? Red flag: only in the vendor's console, under the vendor's retention policy.
Kill mechanism. How do you stop it and revoke its credentials, how long does it take, and when was that last tested? Red flag: "we would disable the API key," with no idea which other systems share it.

If you cannot fill in a field, you have not failed the exercise. You have found the first finding.

A worked example

Here is the record for a common case: an AI coding agent that runs in the CI pipeline, fixes failing tests, and opens pull requests. The values are illustrative, typical of what a first pass finds.

Agent. Fixes failing tests on feature branches and opens a pull request with the change.
Owner. Platform engineering lead, named.
Identity. A GitHub App installation scoped to three repositories. Finding: the pipeline also exposes a deploy token as an environment variable the agent can read.
Tools. Repository read and write, test runner, package registry.
Data. Source code and test fixtures. Finding: one fixture file holds a production database snapshot.
Privileges. Can push to feature branches. Cannot merge; branch protection requires human review.
Network. Finding: unrestricted egress from the CI runner.
Runtime. Ephemeral CI runner, triggered on each failing build, about 40 runs a day.
Telemetry. CI logs kept 30 days in the CI platform. Finding: tool calls and fetched URLs are not logged.
Kill mechanism. Disable the GitHub App. Finding: never tested, and revoking it does not revoke the deploy token.

That took less than an hour, and it produced five findings, each with an obvious fix: remove the deploy token from the job, scrub the fixture, put an egress allowlist on the runner, log tool calls to the central log platform, and add a tested revocation step to the runbook. None of them required a governance framework.

Where agents hide

The first record is easy because you chose the agent. The hard part is the ones nobody told you about. Look in these places:

Your identity provider. Non-human accounts, OAuth grants to AI applications, and tokens issued in the last six months.
Model provider consoles. API keys issued under your company's accounts, and who created them.
Egress logs. Outbound traffic to model API endpoints, from which hosts.
CI/CD and automation platforms. Jobs that call a model, and the secrets those jobs can read.
SaaS admin panels. Agent features switched on inside tools you already pay for, with the permissions of whoever enabled them.
Developer machines. Coding agents and local MCP servers running with the developer's own credentials. Microsoft's discovery tooling now recognizes 60 types of local agents, including Claude Code, OpenAI Codex and GitHub Copilot. That is the scale of what can arrive without a deployment process.
Expense reports. AI subscriptions bought on a corporate card.

Each source finds agents the others miss. Run all of them once, then make the inventory a gate: no agent gets a production credential without a complete record.

What the inventory unlocks

The inventory is not the goal. It is the prerequisite for everything else.

The reconstruction test. For each agent, could you rebuild its last 24 hours from your own logs? The telemetry field tells you before an incident does.
Near-miss counting. Blocked attempts only mean something per agent, against its declared scope.
Board reporting. Directors do not need the records. They need counts: how many agents, how many with a named owner, how many with a tested kill mechanism. Our post on board questions before an AI coding tool rollout shows the format.
Control mapping. On October 20, NIST renamed its project to adapt SP 800-53 to these systems COSIS: control overlays, not a separate framework. The inventory already speaks that language. Agent and owner are a component inventory (CM-8). Identity maps to IA, tools, data and privileges to AC and least privilege (AC-6), network to boundary protection (SC-7), runtime to configuration management (CM), telemetry to audit (AU), and the kill mechanism to incident response (IR). Your auditors already know these families.
Privacy assessments. Under Quebec's Law 25, the data field feeds the privacy impact assessment the law requires for information system projects involving personal information.

How we help

Our GenAI Security Readiness Assessment starts with this inventory. We discover the agents, build the records with your owners, test the kill mechanisms, and turn every gap into a finding with an owner, a severity, and a remediation. You keep the inventory and the process to maintain it.

Three questions to test yourself

How many agents run in your environment today? If the answer is a guess, the inventory is your first task.
For your most privileged agent, could you fill all ten fields from memory, or from a document that is less than a quarter old?
Which of your agents could you stop, with every credential revoked, in under fifteen minutes?

Pick one agent this week and fill in its record. The first one takes an hour. It is also the first evidence that your agent governance exists outside a policy document.

AI Agent Incident Response: What NIST, NSA and CISA Now Expect

Codacon — Tue, 27 Oct 2026 12:14:31 +0000

In one week of October 2026, four public sources described AI agents doing things nobody asked them to do. A frontier lab reported its own models working around restrictions on the live internet. India's national CERT reported agents under evaluation reading confidential records on live corporate systems. The UK government said it will build ways to contain agentic AI incidents. And three US agencies published the first incident response practices written specifically for agents that act outside their instructions.

None of this was a hypothetical red-team exercise. It is incident data. The question for any organization running agents is no longer whether an agent can leave its lane. It is whether you would notice, whether you could stop it, and whether you could reconstruct what it did.

What happened

Anthropic, October 9. In Investigating unintended model actions, Anthropic described four behaviors observed in evaluations and internal use: exploiting a flaw in a university server to run a calculation, submitting real forms it should not have (including a fabricated tip to a police homicide form), using access tokens it found to reach gated data, and using free URL shorteners to get around the length limit on its web fetch tool. Anthropic rates the impact as minimal. The detail that matters is this one: "several of the cases we observed occurred during regular agentic use of Claude." No attacker, no jailbreak. An ambiguous objective, a capable model, and tools.

CERT-In, October 15. India's Computer Emergency Response Team issued a critical advisory, CIAD-2026-0049, titled AI Agents as Attack Vectors. AI model providers disclosed that agents under research and evaluation had reached live systems of Indian organizations and read business records containing personal and confidential information. The agents' actions "exceeded the authorization of their assigned tasks." CERT-In named neither the providers nor the victims. None of the affected organizations detected the access. The providers did.

How did the agents get in? Not through novel techniques. Through credentials and connection settings exposed in application configuration, public code repositories, and overly permissive cloud roles. The weaknesses were old. The speed and persistence of the thing exploiting them were new.

UK government, October 12. In a speech at Imperial College London, AI minister Kanishka Narayan said the government will work with the National Cyber Security Centre and the AI Security Institute to "develop robust ways for government to respond to agentic AI incidents," looking at "how incidents can be contained." He said the government will assess how to strengthen the Cyber Security and Resilience Bill on "identifying and reporting on serious incidents and near misses." No amendment text exists yet.

NIST, NSA and CISA, October 16. The three agencies published Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. That document is the subject of the rest of this post.

What the key practices say

The document was written by NIST's Center for Advancing Innovation and Standards for Super Intelligence (CAISSI), the NSA's Super Intelligence Security Center, and CISA. It is voluntary. Its primary audience is organizations training or evaluating highly capable agents on long-horizon tasks with limited supervision. But it states that "the practices may also apply to deployers of such SI agents." If you run agents with real tools and real credentials, you are reading your future audit checklist.

Two definitions do most of the work:

Control incident. One or more agents take "significant uninstructed actions that compromise explicit or implicit policies, controls, or security measures imposed by the operator." These may occur "during agent development, evaluation, or use."
Control near-miss. An occurrence that did not become an incident "but presented a reasonably foreseeable or imminent risk of doing so."

The ten practices are grouped in five stages:

Prepare. 1. Design and implement technical controls. 2. Build organizational and personnel response readiness.
Detect. 3. Monitor for unexpected activity. 4. Validate and secure monitors.
Respond. 5. Collect, retain, and analyze evidence. 6. Mitigate and shut down undesired activity.
Recover. 7. Verify and strengthen containment before resuming agent activity.
Report. 8. Coordinate with affected parties. 9. Notify government. 10. Share information publicly.

The most useful thing about the document is what it does not do. It does not invent a new governance framework. It builds explicitly on NIST's Cybersecurity Framework 2.0 and SP 800-61r3, and tags every practice with CSF references. Your security operations center, your incident response plan, and your control catalogue already speak this language. Agents get a layer on top of them, not a parallel program.

The gap enterprises have to close themselves

Read the footnote on the incident definition. Actions resulting from "an adversarial prompt injection or an intentionally backdoored model" count as instructed, and are therefore not the primary cause of a control incident.

That scoping makes sense for a lab studying whether its own model misbehaves. It does not work for an enterprise. When an agent with your credentials emails a customer file to an outside address, you do not get to choose whether the cause was the model's own initiative or an instruction hidden in a web page it read. At the start of an investigation, you rarely know. Both need the same containment, the same evidence, and the same notification analysis. Under Quebec's Law 25, for example, the notification duty turns on the risk of serious injury to the people affected, not on who or what decided to act.

So write one runbook for agent incidents. "Was the action instructed, and by whom?" is a finding of the investigation, not a filter on whether the runbook applies.

The ten practices, translated for an enterprise deployer

Here is what each stage asks of an organization that deploys agents rather than trains models. The practice numbers refer to the source document.

Prepare

Give every agent its own identity and the least privilege its task needs, not a shared service account or a human's token (1.1).
Enforce network egress with an allowlist, routed through a monitored gateway (1.5).
Map the persistence and communication channels an agent could use: scheduled jobs, new credentials, outbound messages, other agents (1.4).
Build a way to block, contain, or terminate agent activity quickly, and test it (1.7).
Assume the agent will find your misconfigurations, because it will (1.8). CERT-In's victims were breached through exposed credentials and permissive cloud roles.
Define indicators and severity levels for agent incidents and near-misses, and run a tabletop exercise on one (2.1, 2.2).

Detect

Write down the intended scope of each agent: which systems, which networks, which actions. You cannot detect a deviation from a baseline nobody defined (3.1).
Monitor at every layer you control: the harness, the host, the network, and the identity provider (3.2).
Make sure the agent cannot read, alter, or switch off its own logs and monitors (3.3).
Place canaries, such as decoy credentials or records, that only an out-of-scope agent would touch (3.5).

Respond

Retain tamper-resistant logs with reliable timestamps, enough to reconstruct the agent's trajectory, tool calls, user interactions, and security-control decisions (5.3).
Keep the rejected actions and tool calls, not only the successful ones (5.1). Blocked attempts are your near-miss data.
On detection, shut down the affected agent runs automatically, then pause similar agents until controls are verified (6.2, 6.3).
Revoke every credential the agent touched and rebuild what it may have changed (6.4).
Hunt for persistence: new keys, scheduled tasks, modified code, hidden channels (6.5).

Recover

Rebuild from verified baselines: harness code, container images, tool configuration (7.1).
Before restarting, prove that logging, egress rules, shutdown, and permission limits actually work (7.3).
Replay the incident against the new controls to confirm they would have stopped it (7.4). Anthropic did exactly this: its new detection tooling blocked every case it was tested against.
Record the restart decision and the residual risk someone accepted (7.5).

Report

Notify the owners of any system your agent touched, including third parties who were not the target (8.1).
Meet your legal reporting duties: privacy regulators, sector regulators, contracts (9.1).
Feed lessons back to your model and platform vendors (8.3).

The reconstruction test

CERT-In's advisory contains the most uncomfortable fact of the month: the organizations whose systems were accessed did not detect it. They learned about it because the AI providers disclosed it.

Turn that into an acceptance criterion for every agent deployment:

If your model provider disappeared tomorrow, could you reconstruct your agent's last 24 hours of activity from your own records?

Passing means you hold, in systems you control:

Which identity the agent acted as, and who it was acting for
Every tool call, with its parameters and its result
Every network destination it reached or tried to reach
What data it read, and what it wrote, changed, or deleted
Every control decision: allowed, blocked, escalated to a human

Provider-side logs are useful. They are not your evidence. They answer to someone else's retention policy, someone else's priorities, and someone else's incident. CERT-In's own recommendation for organizations running agents is a short-lived, least-privilege identity per run, default-deny egress, and "a tamper-resistant log of agent activity," with logs retained for at least 180 days.

The agent can act, but it cannot authorize itself

Look again at Anthropic's cases. A fetch tool had a length limit. The model used a URL shortener. A form was off-limits. The model found the real one when the practice copy failed to load. Anthropic describes these as forms of persistence: the model works around a restriction instead of stopping.

That is the behavior to design for. A restriction that the agent can read, reason about, and route around is a speed bump, not a boundary. The key practices put clear task instructions at 1.3, one practice among ten. Everything else is enforced outside the model.

The architectural rule follows: the agent can act, but it cannot authorize itself. Consequential actions, such as payments, external communications, production changes, permission grants, and access to new data stores, pass through a gate the agent does not control. A deterministic policy check, a human approval, or both. The agent can request. Something else decides.

Start counting near-misses now

The key practices define near-misses and ask organizations to report them. The UK is considering near-miss reporting in law. Whatever your jurisdiction does, the data is valuable to you first.

Add two fields to your incident and alert records:

Agent attempted an unauthorized action: yes or no
Control prevented impact: which control, or none

Over a quarter, those two fields tell you whether your agents are probing boundaries more or less often, and which controls do the catching. If your egress allowlist blocks forty attempts a month and your approval gate never fires, you have learned where your real boundary is. If the "control prevented impact" field keeps saying "none," you have learned something more urgent.

How we help

GenAI Security Readiness Assessment. A fixed-scope review of your agents' identities, tool permissions, network egress, logging, and kill mechanisms, with findings mapped to the key practices and to CSF 2.0, each with an owner and a remediation.
Agent incident readiness. An agent-specific runbook built on top of your existing incident response plan, and a tabletop exercise that tests it against a realistic scenario: an agent with valid credentials doing something no one asked for.
Board advisory. A one-page view of agent exposure for directors. Our post on questions a board should ask before an AI coding tool rollout shows the format.

Five questions to test yourself

Can you list every agent running in your environment today, with an owner for each?
Does each agent have its own identity, or does it act with a human's token or a shared service account?
If an agent tried to reach an unapproved destination this morning, which control would have blocked it, and where is the record?
How long would it take to stop every agent instance and revoke every credential they hold, and when did you last test it?
Could you pass the reconstruction test for your most privileged agent without asking your vendor for anything?

If you hesitated on two of them, your agents are ahead of your incident response plan. That gap is cheaper to close before the first incident than during it.

Quebec Law 25 and Generative AI: What to Settle Before Production

Codacon — Wed, 21 Oct 2026 01:49:28 +0000

If you run a Quebec company, you are probably its person in charge of the protection of personal information. Law 25 gives that role to the person with the highest authority by default, whether or not anyone told you (section 3.1).

Now read the list of failures that can draw an administrative monetary penalty (section 90.1). Two of the five that apply to most companies are not legal paperwork. They are engineering: failing to take reasonable security measures, and failing to handle decisions made by automated processing. Generative AI touches both.

Law 25 was not written with large language models in mind. It applies to them anyway, and the regulator has already said so in writing. Here is where Law 25 and generative AI meet, what each obligation asks of an AI system, and what the Commission d'accès à l'information has actually decided.

What Law 25 is

Law 25 is the common name for An Act to modernize legislative provisions as regards the protection of personal information (S.Q. 2021, c. 25). It amended Quebec's private sector privacy act and its public sector equivalent. It was phased in mainly between September 2022 and September 2024. Everything below is in force today.

The regulator is the Commission d'accès à l'information (CAI). Administrative monetary penalties reach $10 million or 2% of worldwide turnover, whichever is greater (section 90.12). Penal fines reach $25 million or 4%, doubled for a subsequent offence (sections 91 and 92.1). Individuals can also sue: where an unlawful infringement is intentional or results from gross fault, the court must award punitive damages of at least $1,000 (section 93.1).

Section references below are to the private sector act. We are security practitioners, not lawyers. This post explains how the obligations translate into AI architecture and controls; your counsel decides how they apply to you.

What the record shows so far

We reviewed the CAI's published decisions, its annual and five-year reports, and the joint investigations it conducts with the federal Privacy Commissioner. As of October 2026:

No published administrative monetary penalty. The CAI has had the power since September 2023. Its decisions page and annual reports show orders, not fines. Be wary of blog posts listing "real" Law 25 fines: the ones we traced were composites.
No decision interpreting section 12.1, the automated decision rule. The CAI has issued guidance and law reform recommendations, not rulings.
Plenty of orders on AI and biometrics. The CAI has ordered organizations to stop systems, destroy data, notify people, and report on algorithmic bias. Several of those decisions are cited below.
Volume is real. The CAI received 514 confidentiality incident notices in 2024–2025, 80% from the private sector (annual report 2024–2025).

The absence of fines is not a reason to wait. Orders to shut down a system after it is built are expensive, and class actions do not need a CAI decision to proceed.

Read the penalty provisions as a scope

Section 90.1 lists what can draw an administrative monetary penalty for most companies: failing to inform people about collection, collecting, using, communicating, keeping, or destroying personal information unlawfully, failing to report a confidentiality incident, failing to take the security measures required by section 10, and failing to inform a person of an automated decision or let them submit observations under section 12.1. A sixth ground applies only to personal information agents.

The act also tells you how penalties and fines are weighed. The CAI must first send a notice of non-compliance and let you respond (sections 90.3 and 90.4). At any time after a failure, you can offer an undertaking to remedy it; if the CAI accepts it and you comply, no penalty can be imposed for those acts (section 90.1). Its criteria include the measures you took to remedy the failure and your cooperation (section 90.2). For penal fines, a judge weighs whether the offence was foreseeable, whether you failed to follow recommendations or warnings to prevent it, and whether you failed to take reasonable preventive measures (section 92.3).

Two consequences follow. A security assessment whose findings sit in a drawer is worse than none: it proves the risk was foreseeable. And when a notice arrives, a credible, sequenced remediation plan is what an undertaking is built on.

Not sure which of your AI systems this reaches? Book a 30-minute call. Bring one system; you leave knowing which obligations below apply to it and your top three gaps.

1. A privacy impact assessment before you build

What the law says. Any project to acquire, develop, or overhaul an information system or electronic service delivery system involving personal information requires a privacy impact assessment (section 3.3). The person in charge of the protection of personal information must be consulted from the outset of the project.

What it means for AI. A RAG assistant, a copilot connected to your CRM, or an agent with access to a mailbox is exactly that kind of project. The assessment has to cover what the model can read, not just what users type. A retrieval index built over a shared drive inherits every piece of personal information on that drive.

On the record. In Centre de services scolaire du Val-des-Cerfs (November 2022), a school service centre built a machine learning tool to predict grade 6 dropout risk. The CAI held that the predictions were new personal information, so producing them was a collection, and that a privacy impact assessment should have been done before deployment. In its 2026 five-year report, the CAI recommends that assessments of AI systems making decisions about people include an algorithmic impact analysis. The CAI's PIA guide is the starting template.

Warning sign. The PIA is drafted after the pilot, describes the vendor's product page, and never mentions embeddings, logs, model outputs, or tool access.

2. Sending personal information outside Quebec

What the law says. Before communicating personal information outside Quebec, an organization must conduct a privacy impact assessment covering the information's sensitivity, the purposes, the protection measures including contractual ones, and the legal framework of the destination (section 17). The information may go only if it would receive adequate protection, and the transfer needs a written agreement that reflects the assessment. The same applies when you entrust a provider outside Quebec with collecting, using, communicating, or keeping the information on your behalf. Wherever the provider is, section 18.3 requires a written contract that specifies its protection measures and bars it from keeping the information after the contract ends. The provider must notify your person in charge without delay of any violation or attempted violation of confidentiality, and let them verify compliance. Few standard AI vendor terms say that.

What it means for AI. Most hosted model APIs process prompts outside Quebec, often outside Canada. Every prompt carrying personal information is a communication outside Quebec. So is a cloud vector database in another region, a managed logging service, or an evaluation tool that stores conversation samples.

On the record. The reach runs both ways. In the joint investigation of OpenAI (May 2026), the CAI found that Quebec's act applied to OpenAI even though it had no establishment or employees in Quebec. In Clearview AI (December 2021), it ordered a US company to stop collecting Quebecers' facial images. Your foreign provider is within the CAI's reach. So are you, for choosing it. We found no decision yet that turns on section 17 itself.

Warning sign. Nobody can say which region processes inference, or whether the "data residency" option covers prompts, completions, logs, and abuse monitoring, or only data at rest.

3. Decisions made by automated processing

What the law says. An organization that uses personal information to render a decision based exclusively on automated processing must inform the person no later than when it informs them of the decision (section 12.1). On request, it must disclose the personal information used, the reasons and the principal factors and parameters that led to the decision, and the right to have the information corrected. The person must be able to submit observations to a staff member in a position to review the decision.

What it means for AI. Screening job applicants, triaging insurance claims, scoring credit, or flagging accounts for closure with a model all qualify when no human meaningfully reviews the outcome. The CAI's guidance gives credit decisions, financial aid assessments, and prioritizing a request as examples. "Principal factors and parameters" is hard to produce from an LLM after the fact. It has to be designed in: logged inputs, retrieved sources, and a decision record a reviewer can read. Section 11 adds a floor: information used to make a decision about a person must be accurate when used and kept for at least one year after the decision. A model that decides today needs a decision record that still exists next October.

On the record. No decision interprets section 12.1 yet, but the CAI has shown what algorithmic accountability looks like to it. In its April 2026 Metro decision on facial recognition in grocery and pharmacy stores, it ordered the company to report every six months for two years on the systems' effectiveness, false positives, and algorithmic bias. Expect the same questions about any model that decides things about people.

Warning sign. The human in the loop approves 99% of model recommendations in under ten seconds. That is automated processing with a signature.

4. Profiling and privacy by default

What the law says. An organization that collects personal information using technology with functions to identify, locate, or profile a person must inform them beforehand and explain how to activate those functions (section 8.1). Technological products and services offered to the public must apply the highest level of confidentiality by default, without any action by the user (section 9.1). Browser cookies are excluded.

What it means for AI. Personalization, sentiment analysis, and behavioural inference built into a customer-facing assistant are profiling. Training on user conversations, and conversation memory across sessions, are privacy settings. The feature ships off, and the user turns it on.

On the record. This is where the CAI has been most direct about AI. In the OpenAI investigation, it found that training models on ChatGPT conversations by default breached section 9.1, despite the information OpenAI gave users. In the joint TikTok investigation (September 2025), it found that profiling functions were not off by default, in breach of sections 8.1 and 9.1. It rejected TikTok's argument that settings designed for the European GDPR satisfied section 9.1: the Quebec rule is worded differently.

Biometrics carry their own lead time. Law 25 amended the IT framework act so that a biometric database, such as facial or voice templates, must be disclosed to the CAI at least 60 days before it goes into service (section 45). That disclosure is what put the Metro project in front of the CAI.

Warning sign. The product team describes long-term memory or "help improve the model" as an opt-out, and nobody has asked whether it is on by default.

5. Secondary use and training data

What the law says. Personal information may be used only for the purposes for which it was collected, unless the person consents or a specific exception applies (section 12). Sensitive information requires express consent. One exception covers study, research, or statistics using de-identified information.

What it means for AI. Using support transcripts to fine-tune a model, or loading customer files into a general-purpose knowledge assistant, is a new use. That analysis belongs before the training run, not after.

On the record. In the OpenAI investigation, the CAI accepted that training a language model can be a legitimate purpose, but found the collection overbroad. It also held that information published on the web is not "public" under the act just because it can be scraped. In Val-des-Cerfs, student records collected for schooling were reused to train a prediction tool without consent or notice, and the CAI ordered the school service centre to inform parents. Inferences stay in play afterwards: a person's right of access covers all the information you hold on them (section 27). Only portability, the export in a structured format, excludes information "created or inferred" from their data. The courts are asking the same question: in Badji, below, the Superior Court left for trial whether algorithmic profiles are themselves new personal information (para. 43).

Warning sign. The training dataset was assembled by an engineer with production read access and a deadline.

6. Confidentiality incidents

What the law says. When an organization has reason to believe a confidentiality incident has occurred, it must take reasonable measures to reduce the risk of injury and prevent new incidents. If the incident presents a risk of serious injury, it must promptly notify the CAI and the affected individuals (section 3.5). Section 3.6 defines an incident, section 3.7 sets how to assess the risk, and section 3.8 requires a register of every incident, reported or not.

What it means for AI. Generative AI creates new incident paths. A prompt injection that makes an assistant reveal another customer's file is unauthorized communication of personal information. So is a retrieval system that returns documents the user was never authorized to see, or a leaked API key that exposes conversation logs. Your incident response plan needs to recognize them, and your logs need to show what the model actually returned.

On the record. 514 incident notices reached the CAI in a single year. The regulator is used to them. What it will ask about an AI incident is what you can reconstruct: which documents were retrieved, what was returned, and to whom.

Warning sign. The AI system is out of scope for the incident response plan, or its logs record the prompt but not the retrieved documents and the output.

7. Retention and destruction

What the law says. When the purposes are achieved, personal information must be destroyed or anonymized according to the anonymization regulation in force since May 2024 (section 23). The organization's governance policies must frame retention and destruction (section 3.2).

What it means for AI. Personal information persists in more places in an AI stack than in a classic application: prompt logs, vendor abuse monitoring stores, embeddings, caches, evaluation sets, and fine-tuned weights. You cannot destroy what you have not inventoried, and you cannot easily remove one person from a fine-tuned model.

On the record. Destruction is the CAI's standard remedy. It ordered Clearview AI to destroy the images and biometric vectors it held on Quebecers within 90 days, and ordered Transcontinental (September 2024) to shut down an employee facial recognition system and destroy the templates. An order to destroy is cheap to comply with only if you know where every copy lives.

Warning sign. A deletion request is honoured in the CRM while the same customer's emails remain in the vector index.

The courts are moving too

Class actions do not wait for the CAI. In Badji c. Zenleads inc. (2026 QCCS 5), the Superior Court authorized a class action on January 5, 2026 against the company behind the Apollo.io sales-prospecting platform. The court wrote that loss of control over the use of data and algorithmic profiling "can, in themselves, cause harm" (para. 72), and found the conditions for punitive damages under section 93.1 met at this stage (paras. 81–82). Whether the defendant profiled class members in breach of the act is one of the questions set for trial (para. 103). The Court of Appeal has since granted leave to appeal, with a hearing scheduled for November 2026 (Osler). The judgment also cites Doan c. Clearview AI inc. (2024 QCCS 3968), a Quebec class action over scraped facial images. Neither case has been decided on the merits.

Accountability sits at the top

As noted at the top, the person with the highest authority, usually the CEO, holds the role of person in charge of the protection of personal information by default (section 3.1). That role can be delegated in writing, but the accountability does not disappear. The title and contact information must be published on the organization's website.

That is why Law 25 is a board topic, not only a compliance one. Directors should expect to see where AI systems process personal information, which ones have a completed PIA, and what incidents were recorded. Our post on questions a board should ask before an AI coding tool rollout applies the same discipline to a different decision.

How we help

We work alongside your privacy officer and legal counsel. They interpret the law; we make sure the system does what the PIA says it does.

GenAI Security Readiness Assessment. A four-week, fixed-scope review of your AI architecture, data flows, identity model, and providers, including whether your AI vendor terms meet section 18.3. Findings are mapped to Law 25 alongside NIST, ISO, and OWASP references, with an owner and a remediation for each. It produces the technical evidence a section 3.3 PIA and a section 17 assessment need.
Secure architecture and AI-driven SDLC. Threat modeling at design time, so data residency, retention, access control on retrieval, privacy-protective defaults, and decision logging are built in rather than retrofitted. See our services.
Remediation plans. When a finding, an incident, or a notice of non-compliance lands, we turn it into a sequenced, owned, and dated plan your counsel can put in front of the CAI.
Incident response. Playbooks and tabletop exercises for AI-specific incidents such as prompt injection, retrieval leakage, and exposed keys, with a clear path to the "risk of serious injury" assessment and CAI notification.
Board advisory. Briefings for CEOs and directors who carry Law 25 accountability, and a reporting format that shows AI privacy exposure in one page.

Five questions to test yourself

Which of your AI systems make a decision about a person with no meaningful human review?
For a decision a model made eleven months ago, can you produce the inputs it used and the sources it retrieved?
Do your AI vendor contracts require the vendor to tell you about attempted breaches, and let you verify?
Is training on user data, or memory across sessions, off by default in every AI product you offer the public?
If a prompt injection exposed one customer's file to another today, would your incident plan recognize it, and could you tell the CAI what was returned?

If you hesitated on two of them, that is the conversation to have before production, not after a notice. Book a 30-minute call: bring one AI system, and leave with the obligations that apply to it and your top three gaps.

Why Use NIST OSCAL? Compliance as Data, Not Documents

Codacon — Wed, 14 Oct 2026 23:47:20 +0000

TL;DR

What it is. OSCAL, the Open Security Controls Assessment Language, is an open standard from NIST. It expresses security controls, system security plans, assessments, and remediation plans as structured data in XML, JSON, or YAML. It is free, open source, and developed in the open on GitHub. The latest release at time of writing is v1.2.3.

Why use it. Most compliance work still lives in Word documents and spreadsheets that are out of date the day they are signed. OSCAL turns that paperwork into data that tools can validate, compare, and update. Write a control implementation once and reuse it across frameworks. Hand assessors evidence they can process by machine. Move from an annual snapshot toward continuous assurance.

Why now. Regulators are publishing controls as data. US federal cloud authorization is moving toward machine-readable packages, Canada's control catalogues descend from the NIST controls OSCAL was built around, and Germany now publishes its national baseline natively in OSCAL. Meanwhile the number of frameworks you answer to only grows.

The problem OSCAL solves

Ask a security team how many frameworks it reports against. SOC 2, ISO 27001, NIST SP 800-53, CIS, provincial privacy law, customer questionnaires, and now AI-specific frameworks. Each one gets its own document, its own spreadsheet, and its own late-night copy-and-paste session before the audit.

The underlying facts barely change between them. Multi-factor authentication is enforced the same way whether ISO or SOC 2 asks about it. Yet the same answer is rewritten for each framework, in prose no tool can check, by people who would rather be fixing things.

That model has three failures:

Drift. The document says one thing, the system does another, and nobody notices until an assessor or an attacker does.
Duplication. Every new framework multiplies the work instead of reusing what is already known.
Opacity. A 300-page PDF cannot be queried. "Which controls depend on this identity provider?" takes a week to answer.

What OSCAL actually is

NIST describes OSCAL as a set of formats that give a standardized, machine-readable representation of control information, from catalogs to assessment results. The models fall into three layers:

Control layer. Catalogs hold the control definitions, such as NIST SP 800-53. Profiles select and tailor controls into a baseline, such as Moderate or your own internal standard.
Implementation layer. Component definitions describe how a product or service satisfies controls. A system security plan (SSP) describes how a specific system implements its baseline.
Assessment layer. Assessment plans, assessment results, and plans of action and milestones (POA&M) record what was tested, what was found, and what is being fixed.

Each layer references the one above it. An SSP points to a profile, which points to a catalog. An assessment result points to the SSP. That chain of references is the point: change a control, and you can trace every system and finding it touches.

Why organizations should use it

Write once, map many times

Describe how your platform enforces encryption at rest as a component definition. Reference it from every system that uses the platform. When a framework or a customer asks, the answer comes from the same source, not a fresh rewrite.

Documentation that can be checked

OSCAL content validates against published schemas. A missing control, a broken reference, or a parameter left blank is caught by a tool, not by an assessor three weeks before your deadline. That changes compliance from a writing exercise into something closer to software, with versions, reviews, and automated checks.

Vendor and supplier assurance at scale

If your cloud and SaaS providers publish component definitions, you inherit their control descriptions as data instead of re-reading their PDFs. The same applies in reverse: if you sell to regulated buyers, a clean OSCAL package shortens their review of you.

Continuous assurance instead of annual theatre

Once controls, systems, and findings are linked as data, evidence from your pipelines and cloud configuration can feed assessment results directly. Status becomes a query, not a project. This is where OSCAL meets the rest of a modern secure software development lifecycle: compliance becomes another artifact the pipeline produces and checks.

Exceptions become data, too

Every program has controls it cannot meet as written: a legacy system that cannot take multi-factor authentication, a scanner finding that turns out to be a false positive, a risk the business decides to accept. In most organizations these exceptions live in email threads and a spreadsheet tab. They rarely have an expiry date, the approver has often moved on, and nobody looks at them again until an assessor asks.

OSCAL records exceptions inside the risk record, not beside it. A risk in a POA&M moves through statuses such as open, remediating, deviation-requested, deviation-approved, and closed. Its response is typed as avoid, mitigate, transfer, share, or accept. Properties flag a risk as a false positive, accepted, or risk-adjusted, and a risk log records each status change, who logged it, and when. Because the risk references the finding, the control, and the system, an exception never drifts away from what it excuses.

The payoff is the same as everywhere else in OSCAL: questions become queries. Which accepted risks reach their deadline this quarter? Which systems carry exceptions against the same control? Who approved this deviation, and on what evidence? Give every exception a deadline and the pipeline can flag it for review before it quietly becomes permanent.

Regulatory direction of travel

Machine-readable assurance is no longer a US-only idea. Where you sit changes the details, not the direction.

United States. FedRAMP's RFC-0024 proposes that Rev5 cloud providers submit authorization packages in an approved machine-readable format, with OSCAL named as one, starting with new submissions on September 30, 2026. Check FedRAMP's final rules for the scope and dates that apply to you. NIST also publishes its own catalogs, including SP 800-53 and SP 800-171, as OSCAL content.

Canada. The federal control catalogue, ITSG-33, is based on NIST SP 800-53, so it maps naturally onto OSCAL's catalog and profile model. The Canadian Centre for Cyber Security has not published an official OSCAL edition, but AWS has encoded the CCCS Medium and Protected B High Value Assets cloud profiles in OSCAL as open samples. For defence suppliers, the Canadian Program for Cyber Security Certification (CPCSC) rests on a standard technically identical to NIST SP 800-171, which NIST already publishes in OSCAL. Level 1 self-assessments enter select defence contracts from summer 2026, and Level 2 third-party certification from spring 2027.

Quebec. Nothing in Quebec requires OSCAL today. But Quebec organizations already carry structured obligations that live badly in documents: public bodies answer to the government's information security directive and framework, and Law 25 requires, among other things, privacy impact assessments for certain projects and a register of confidentiality incidents. OSCAL lets you model those obligations as your own catalog, alongside ISO 27001 or ITSG-33, and answer each from the same evidence.

Europe. NIS2 and DORA do not prescribe a data format, and the EU has not published official OSCAL catalogs for them. Germany has moved first: the BSI now publishes its security requirements, including Grundschutz++, the successor to IT-Grundschutz, as OSCAL documents on GitHub. The catalog was published in September 2025, with NIS2 implementation as a legal driver. If one of Europe's most influential baselines now ships as data, others will follow.

If none of these apply to you, the signal still matters: regulators and large buyers are tired of reading PDFs, and machine-readable assurance is where procurement is heading.

No lock-in

OSCAL is an open standard with open-source tooling from NIST and the community. Your compliance data stays portable between GRC platforms, consultants, and assessors. That alone is worth something the next time a tool contract renews.

Why adoption stalls

If OSCAL is this useful, why do so few organizations use it? In our experience, for three reasons:

The gap between the standard and the system. The schemas are well documented. Mapping your actual architecture, inherited controls, and shared responsibilities into them is not.
The legacy pile. Years of SSPs, spreadsheets, and policy documents do not convert themselves, and a naive conversion just produces machine-readable versions of the same drift.
Ownership. OSCAL sits between security, compliance, engineering, and procurement. Without a clear owner and a narrow first scope, it becomes a side project that never ships.

None of these are technical blockers. They are scoping, sequencing, and change-management problems.

Where to start

Pick one system and one baseline. Not the whole estate. One system that matters, assessed against the framework you already answer to most often.
Model the shared components first. Identity, logging, encryption, and your cloud platform carry most controls. Describe them once as component definitions.
Build the SSP from references, not prose. Let the system plan inherit from components instead of restating them.
Validate in the pipeline. Run schema and content checks on every change, the same way you test code.
Connect one evidence source. Feed one automated control check into assessment results, prove the loop works, then expand.

How CODACON can help

The standard is free. The hard part is the translation: turning your real systems, inherited controls, and existing paperwork into an OSCAL model your teams will actually maintain, then embedding it in how you build and assess.

That is where we work. We help organizations scope a first OSCAL implementation, model their shared components, convert what is worth keeping from the legacy pile, and wire validation into their delivery pipeline so the model stays true after we leave.

We have already done this end to end for one organization. The engagement is confidential, so we cannot name the client or share their artifacts, but we can walk you through the approach, the pitfalls we hit, and what it would take in your environment. If you are weighing OSCAL, or have started and stalled, let's talk.