Governing AI is now a product, not a policy

Proofpoint announced a system that treats data security and AI security as one connected risk, giving agents access only to the data their intent requires and turning existing business policies into runtime controls.

Salesforce announced its Enterprise AI Harness and AI Control Plane. Its release says new capabilities and the unified experience are planned to begin rolling out in early fiscal FY28; an announcement is not evidence they were already available in September.

Teradata announced Tera as an agentic coworker. It says Context Engine, Harness and Agent Skills will be available in Q4 2026. The vendor announcement is not an independent test of effectiveness.

Three different vendors, converging on the same missing piece: agents are only as safe as the layer that decides what they may touch. The model is becoming the commodity. Context, permission and audit are becoming the product.

That should change what a board asks about. Not "which model are we using?" but "what can it reach, on whose authority, and where is that written down?"

Map agent access the way you map employee access. Least privilege applies to software that acts, too.

Log intent, not just output. When something goes wrong, you need to know why the agent thought it should act.

Keep the control layer vendor-neutral. You will change models. You should not have to change your governance every time you do.

In 2021 Coop was hit by an IT attack, and Scan & Pay still had to work for customers. Read the Coop case. Resilience is decided long before the incident — by what leaders chose to prioritise.

If your board wants to understand AI risk without the jargon, see the AI keynote or advisory for leadership teams.

A governance demonstration should include an action the agent must not take. Ask the supplier to show an attempted read of restricted information, an unauthorised write and a task whose permission has just been withdrawn. Observe the refusal and inspect the record, rather than accepting a diagram of the intended controls.

Next, ask where enforcement actually happens. Does the rule stop the tool call, or merely tell the model not to make it? Who can change the rule, and can that change be traced? Require a clear distinction between a model’s explanation of its behaviour and a record of the permissions and actions involved.

Central oversight and local ownership need not be competing designs. Consider shared minimum controls with business owners accountable for specific workflows. The trade-off to examine is consistency versus the detail needed to govern each task.

Do not make that assumption in the purchase decision. Ask what still depends on source-system permissions, identity management, operational monitoring and human review. Make the boundaries explicit, including what remains outside the product’s coverage.

Who can stop an agent if the control service is unavailable? Test the agreed response, including legitimate work that must continue without the agent. The Coop case offers a resilience discussion grounded in an actual disruption, not evidence for any security product. Pair procurement questions with the incident analysis to examine response ownership as well as prevention.