DEV Community: Codacon

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.

What Should a Board Ask Before Approving an AI Coding Tool Rollout?

Codacon — Sun, 06 Sep 2026 02:10:09 +0000

Vendor demos show how fast AI can write code. The proposal in front of the board should show what happens when that code is wrong.

Before approving an AI coding tool rollout, directors need more than a productivity promise. They need evidence of value, clear limits on access, and someone accountable for stopping the rollout if those limits fail.

Here are the questions that turn an impressive demo into a defensible decision.

Where the board's job starts and stops

A board does not approve every developer tool. It governs material exposure and delegated authority. An AI coding tool crosses that line when it can read source code, hold secrets, or change production systems. Management owns implementation. The board owns the conditions for proceeding.

We frame the questions using the NIST AI Risk Management Framework 1.0 (Govern, Map, Measure, Manage), its Generative AI Profile, NIST AI 600-1, for AI-specific risks, and the Secure Software Development Framework, SP 800-218, for software assurance. NIST describes the AI RMF as voluntary. The questions are our application of that guidance, not a NIST checklist, a certification, or a legal requirement.

1. What business outcome are we buying, and how will we prove it?

Why it matters. Code volume is not a business outcome. Faster code can also mean more review, defects, and rework. METR's July 2025 randomized study found that 16 experienced open-source developers took 19% longer on 246 tasks when allowed to use early-2025 AI tools, while believing they had been faster. METR cautions against generalizing to other teams or current tools, but the lesson holds: perceived speed is not measured speed.

Evidence to request. A baseline taken before the pilot and repeated after: delivery lead time, defect rate, review time per change, rework, and total cost. The AI RMF asks organizations to document expected benefits and costs, including non-monetary ones (MAP 3.1 and 3.2).

Warning sign. The business case rests on the vendor's productivity figure or on "acceptance rate," the share of suggestions developers kept.

2. What can the tool read, retain, transmit, and change?

Why it matters. Exposure depends on permissions, not product names. Suggesting code in an editor is one thing. An agent that runs commands, edits repositories, and triggers deployments is another. AI 600-1 (section 2.9) describes indirect prompt injection: instructions hidden in content the AI reads, such as a code comment or a web page, that can cause it to leak data or run malicious code. Autonomy multiplies that risk.

Evidence to request. A data map: what source code, secrets, and customer data the tool can access, what the vendor retains and for how long, whether inputs train models, and which subprocessors are involved. A permission map: what the tool can execute, commit, and deploy, and whether a human approves each step. Suggest, execute, and deploy should each carry their own approval conditions.

Warning sign. "The vendor doesn't train on our data," with no confirmation that the statement applies to the tier and settings actually purchased.

3. What evidence shows our controls work with AI-generated code?

Why it matters. The SSDF describes practices for reducing vulnerabilities in released software, limiting their impact, and preventing recurrence. Our position: AI-generated code must pass the same assurance process as any other code. The risk is that volume overwhelms it. AI 600-1 names automation bias, the tendency to defer to machine output, as a risk in its own right (section 2.7).

Evidence to request. Pilot results from the company's own repositories and workflows, not a vendor sandbox (MEASURE 2.3). Confirmation that human review, security testing, dependency and licence checks, and build pipeline protection apply to AI-generated changes. Reviewer capacity: changes per reviewer per week, before and after.

Warning sign. Approval times fall while change volume rises. That is rubber-stamping, not efficiency.

4. Who is accountable when something goes wrong?

Why it matters. The AI RMF places responsibility for AI risk decisions with executive leadership (GOVERN 2.3). A rollout owned by "engineering" has no one to call when the tool pushes a credential to a public repository.

Evidence to request. A named executive sponsor with documented acceptance of residual risk. A responsibility matrix spanning engineering, security, legal, and procurement. An exception process: who can grant broader access, and who is informed.

Warning sign. Accountability is shared, or sits with the champion who selected the tool.

5. What vendor and contractual risks are we accepting?

Why it matters. The tool is a supply-chain dependency. The AI RMF asks for third-party risk policies, including intellectual property, and contingency plans for third-party failures (GOVERN 6.1 and 6.2). AI 600-1 notes that the legal status of generated content resembling copyrighted work is still debated (section 2.10). Contract terms are the practical answer, and they vary by tier.

Evidence to request. A vendor assessment covering confidentiality, intellectual property protections and their limits, incident notification timelines, the vendor's right to change models or terms, and exit arrangements including data deletion. A continuity plan if the service is withdrawn. SP 800-218A, NIST's profile for building AI models, applies to vendor diligence, not to the company's developers.

Warning sign. Legal reviewed the standard terms, but nobody confirmed which apply to the purchased configuration.

6. What are the pilot's success criteria and stop conditions?

Why it matters. The AI RMF expects mechanisms and assigned responsibility to disengage or deactivate a system behaving inconsistently with its intended use (MANAGE 2.4). A pilot without stop conditions is a rollout with extra steps.

Evidence to request. Phased access starting with low-risk repositories and non-production environments. Acceptance thresholds set in advance. Incident triggers that pause the pilot: a credential exposure, a vulnerable change reaching production, a data-handling breach. A tested revocation: someone has turned off access and timed it.

Warning sign. Success criteria are written after the pilot, or the stop authority's objectives depend on the rollout.

7. What will the board see after approval?

Why it matters. Approval starts oversight. The AI RMF calls for post-deployment monitoring, incident response, and change management (MANAGE 4.1).

Evidence to request. A one-page quarterly dashboard: outcomes against baseline, adoption by team, defect and rework trends, security incidents involving the tool, control exceptions granted, and exposure changes such as new permissions, model versions, or repositories in scope.

Warning sign. The first report covers adoption and satisfaction only.

Hypothetical example: evidence changes the decision

Illustrative scenario, not a client case. A manufacturer's CTO proposes a company-wide rollout of a coding agent, citing a vendor claim of 40% faster delivery. The audit committee asks for question 1 and 3 evidence. A six-week pilot on two internal services shows lead time down 11%, review time per change up 30%, and two vulnerable dependencies caught only after merge. The committee approves suggestion-only mode across engineering, keeps execute permissions with the pilot teams for one more quarter, and requires reviewer capacity and scan coverage in the next report. Same tool, different decision.

Approval checklist

Baseline and post-pilot measurements of outcomes and cost
Data map and permission map, with separate conditions for suggest, execute, and deploy
Evidence that review, security testing, and pipeline controls cover AI-generated code
Named executive owner, responsibility matrix, and exception process
Vendor assessment, contract terms confirmed for the purchased tier, continuity plan
Written success criteria, incident triggers, and a tested revocation
Quarterly dashboard format agreed

Three decisions

Approve a bounded pilot when the value case is credible but unproven, and the pilot stays in low-risk environments with stop conditions.

Approve expansion subject to conditions when pilot evidence meets the thresholds and the remaining gaps are named, owned, and dated.

Defer pending evidence when management cannot yet answer questions 1, 2, or 6. That is not a rejection. It is oversight.

For an independent view on rollout readiness, our GenAI security readiness assessment covers this ground.