Cybersecurity briefing
/
feb 16, 2025
AI Governance Has to Follow Agents Into Production
Collibra's trail ML acquisition highlights a gap: AI approvals go stale as agents change. Here's how to keep governance tied to what agents can do today.
/
AUTHOR
Jeff Dyer
Overview
Collibra’s October 5 acquisition of trail ML puts a practical problem at the center of the AI governance market: an approval can remain on file long after the system it covered has changed. An agent that once summarized documents may later gain access to a customer database, a payment tool, or an external service. For organizations expanding AI into everyday operations, the difficult question is how to keep those changes within the authority the business actually approved.
In its acquisition announcement, Collibra describes combining its enterprise governance context with trail ML’s evidence analysis, control assessment, workflow automation, and runtime enforcement. The company says assessments can be triggered again as supporting evidence changes. These are vendor statements about the combination’s capabilities and direction, rather than independent findings about implementation results. They nevertheless identify an important architectural requirement: governance must stay connected to the systems being governed.
The agent can change without changing its name
Consider a hypothetical finance assistant initially approved to read invoices and prepare a reconciliation summary. Its owner subsequently adds a tool that updates supplier records. A later change gives it access to an outbound messaging service so it can resolve discrepancies. Each addition may appear reasonable in isolation. Together, they give the agent a different operational role from the one described in its original assessment.
The consequences depend on the details. Reading an invoice and changing a supplier’s bank account require different controls. Sending a summary to an internal reviewer differs from transmitting its contents outside the organization. A register that records only the assistant’s name, model provider, and business purpose cannot capture those distinctions.
An effective assessment should therefore describe the deployed agent’s authority: which identities it uses, which resources it can reach, which operations its tools expose, and where information can leave the workflow. That record needs a version and a date. Otherwise, a reviewer cannot establish whether the configuration running today is the configuration previously approved.
The same principle applies to a legal research assistant that gains a document-sharing function or a manufacturing agent that moves from recommending maintenance to creating work orders. These are illustrative scenarios, not incidents reported in the acquisition announcement. Their value is that they make the governance question specific enough to test.
A live inventory changes what reviewers can ask
Continuous oversight begins with evidence of what exists. Approved projects are only part of that picture. Teams also need to discover agents introduced through development tools, endpoints, cloud services, and business applications, then connect them to an accountable owner. The inventory becomes useful when it records relationships as well as assets.
Geordie AI, for example, maps agents and their configurations, including connected tools, permissions, models, and knowledge sources, across supported environments. Its behavioral observability capabilities add a record of agent activity and tool invocations. Taken together, those views help a reviewer compare what an agent is configured to do with what it has actually done, rather than rely exclusively on its owner’s description.
The distinction matters because configuration and activity answer different questions. Permission to export customer records is an exposure even if no export has occurred. An unexpected attempt to use an external tool is evidence requiring investigation even if an enforcement control blocks it. Combining the two makes it possible to review both excessive authority and departures from the intended workflow.
Coverage should be established against the actual agent frameworks and deployment paths. An inventory with undisclosed gaps can give a governance committee unwarranted confidence. Organizations should also decide what activity evidence they need to retain and how sensitive content will be handled before collecting prompts, responses, or tool arguments.
Review should follow material changes
Continuous governance does not require a committee meeting for every prompt edit. It requires a defensible definition of changes that alter risk. Adding write access, introducing a new external destination, changing the data population, or replacing a tool with one that executes code should trigger a review proportionate to the new authority.
For the finance assistant, a reviewer might allow invoice reading to continue while withholding permission to change supplier details. The existing workflow need not be suspended merely because a proposed expansion needs scrutiny. Approval can remain specific to the actions, resources, and conditions the organization has tested.
Technical enforcement then needs to reflect that decision. An application authorization rule may prohibit a write operation. A scoped identity may restrict accessible records. An agent-level policy may require human approval for a consequential action. Geordie’s Beam documentation describes monitoring and active policy controls for supported agent architectures. Organizations implementing such controls should verify the precise intervention point and test alternate routes to the same resource, including direct access that bypasses an agent tool.
A successful blocked-action test is evidence about a particular control path. It does not establish that every possible route is governed. That is why application permissions, identity controls, and agent oversight need to be designed together.
Evidence needs an owner and a response
The acquisition also raises a question beyond automation: who decides what changed evidence means? An assessment can be refreshed automatically, but responsibility for accepting risk, resolving an exception, or withdrawing authority still needs to be assigned.
NIST’s AI Risk Management Framework provides a voluntary foundation for managing AI risk across design, development, use, and evaluation. Mapping findings to a framework can organize the work. The practical evidence must still show which system was assessed, which configuration was tested, what the control did, and who authorized any exception.
For an organization starting this work, the first step is to select one production agent and compare its current access with its original approval. Record the differences, test the controls around its most consequential action, and establish which future changes require another review. Then assign someone to act on that evidence. AI governance becomes credible when the approval record remains an accurate description of what the agent is allowed to do today.
/
BLOG
