Boards Are Drawing Bright Lines for AI Agents. Security Has to Enforce Them.

Chris Hughes

October 13, 2026

A new AIUC-1 whitepaper tells boards what agent oversight should look like. Read from the security side, it is really a list of evidence security teams are about to be asked for.

If you have spent time in front of a board or audit committee lately, or even security leaders, you have likely heard some version of these questions: how many AI agents do we have, what are they allowed to do, and how do we know they are behaving? Most organizations still can’t answer with evidence, and it comes up frequently in conversations with my network.

The AIUC-1 Consortium's new whitepaper, Board Accountability and Agentic AI, is a useful prompt. It is written by and for directors, and it is worth their time. Rather than summarize it, I want to take what it asks of boards and translate that into what security teams actually have to build, enforce and report. I recently discussed some of its highlights both with Noma’s CAB attendees, as well as during a recent lecture of mine at Carnegie Mellon and it resonated with technology and security executives, given the current landscape many are trying to govern.

So, let's check it out!

What the Whitepaper Asks of Boards

The short version is that boards own agent risk, regulators are leaning on existing fiduciary duties rather than waiting for new rules, and oversight has to move from principles to operational governance. The most important shift is that boards should stop reviewing individual agent decisions and instead pre-authorize decision boundaries, aka the bright lines agents cannot cross without human oversight, along with protocols for when those lines are breached.

This is a good model, and it is critical as organizations continue to see the number and type of agents scale across their environments. Boards already govern this way with delegations of financial authority, but nobody accepts a signing limit that exists only in a policy document. The ERP enforces it and an internal audit verifies it. Agent boundaries deserve the same treatment, and that work lands on security.

*Adapted from the three-layer governance model in the whitepaper.

The paper is clear that boards and technical teams govern different things. What it leaves implicit is that the bottom layer is where a bright line either becomes real or quietly does not. APRA made the same point in its recent letter to industry, criticizing entities for leaning on policy and after-the-fact detection instead of enforceable technical controls. The reality is that as we move from LLM’s that give answers to agentic systems that take actions, assurance can’t rest in static policy documents and instead must be governed at runtime, with verifiable evidence and enforcement.

From Board Expectations to Security Deliverables

Here is how I would translate the AIUC-1 paper's asks into work security teams own. The left column is the board's language. The other two are ours.

What boards are being asked to do	What security has to deliver	What counts as evidence
Turn AI principles into measurable controls	Policies expressed as enforceable rules on agents, tools and data, not documents	Policy coverage by agent and tier, with violations logged
Pre-authorize decision boundaries	Runtime enforcement on prompts, tool calls and actions	Blocked actions, policy hits and agents found operating above their approved level
Approve agent classification levels	Identities, permissions and approval gates mapped to each level	A permission map per agent and approval logs tied to executed actions
Demand enterprise visibility	Continuous discovery across cloud, code, SaaS and employee endpoints, with an owner per asset	A live inventory with first-seen and last-seen dates, not an annual survey
Obtain independent assurance	Recurring adversarial testing, and direct evidence access for risk and audit	Red-team findings and retests triggered by change, readable without going through delivery teams
Set escalation protocols	Detections routed to the SOC and a defined path from incident to board	Time to detect and contain, near-misses and open exceptions by age

Classification Levels Are Security Controls

The whitepaper's appendix includes an example four-level agent classification, from prohibited (Level 0) to bounded autonomy (Level 3). Read the definitions with a security hat on, and every level is a bundle of technical constraints such as which identities an agent uses, which tools it can call, whether a human sits in the loop, and whether anyone can stop it. Security should be in the room when the levels are written, not handed them afterward.

Three things break this model in practice:

Classification drift. An agent approved at Level 1 gets a new MCP server or tool with write access, and it is now operating as a Level 2 or 3 agent nobody approved. Levels need re-evaluation when agents change, not just when they launch.
Agents that were never classified. You cannot apply a level to an agent you do not know exists. This is getting more urgent as coding and productivity agents spread across employee laptops. They inherit the credentials, browser sessions and connected accounts of the person running them, and MCP servers and skills extend that reach into repositories, databases and SaaS systems, often before anyone has decided which level they belong in.
Agents interacting with agents. Per-agent classification does not capture what happens when a Level 1 agent's output becomes a Level 3 agent's instruction.

Reporting That Holds Up

The paper suggests board metrics such as inventory by risk tier, incidents and time to contain, open exceptions and control coverage. It’s a good list but my caution is that every one of those metrics is only as good as the telemetry underneath it. A count of agents by tier built from a survey is fiction by the time it reaches the board pack, and self-attested control coverage is exactly the kind of assurance APRA criticized.

Each board metric should trace back to a control that generates it automatically. If a number cannot be traced to one of these stages, treat it as an opinion rather than evidence.

Agents change their tools, prompts and models constantly, so the evidence has to be continuous, and risk and audit need to pull it directly rather than waiting on the teams they are meant to challenge. That is what independent assurance looks like for agents.

Closing Thoughts

A few questions worth sitting with.

Could you produce an inventory of every agent, MCP server and skill in your environment today, including the ones running on employee laptops?
If an agent quietly picked up write access last week, would you know it had moved up a classification level?
If a director asked how you know a bright line held, would your answer be a policy document or a log?

Those are some of the questions we built Noma to answer, from the employee endpoint to the SaaS and homegrown agents running across the rest of the business.

Boards are going to draw the bright lines either way. The real question is whether anyone can prove the agents stayed behind them. Security can treat that as another reporting burden, or as a seat at the table in defining the levels, a mandate to enforce them, and a reason to finally replace point-in-time attestations with continuous evidence.

Ready to learn more about how Noma can help? Book a demo.

Source: AIUC-1 Consortium, Board Accountability and Agentic AI, led by Louise McElvogue.

READ TIME

9 min