All posts
    AI AgentsAI GovernanceData Security

    Governing AI Agents: Why Monitoring Is No Longer Enough

    8 min read

    Enterprise AI has moved beyond isolated copilots. Agents now search internal knowledge, call business applications and pass information to other agents. As that footprint grows, organisations are discovering a basic problem: knowing that an agent exists does not tell you what data it can see, what it sends to a model or what it reveals in its answer.

    A 2026 Dataiku study conducted by Harris Poll among 685 CIOs found that 81% lack complete oversight of agents created outside approved systems. Seventy-two per cent cannot consistently measure whether all their agents deliver business outcomes, while 47% have already decommissioned more than 20 agents this year. These figures describe a visibility and accountability gap. They do not prove that every retired agent failed because of a security incident. Read the source study.

    The market is building a control layer

    Recent launches from governance, identity and security vendors show a common direction: enterprises need a control layer above fragmented agent platforms. Inventory, ownership, lifecycle status, cost and performance all belong in that layer. They answer important questions: which agents are running, who owns them and whether they are producing value.

    But visibility is not enforcement. A dashboard can show that an agent called a customer database. It cannot, by itself, prevent that agent from including an email address, an IBAN, a patient identifier or a contract value in a request to an external model.

    The missing question: what data crosses the boundary?

    Every agent sits at the intersection of identity, tools and data. Authentication answers who the agent is. Authorisation determines which system it may call. Runtime data governance determines what information may cross from that system into the model, and what may return to the user or the next agent.

    • Before the model call: detect sensitive entities in prompts, retrieved documents and tool results
    • At policy time: tokenize, mask or block according to data type, role, organisation and model provider
    • After the model call: inspect the response before it reaches a person, application or downstream agent
    • For audit: record the detection, policy decision, action, actor and timestamp for every interaction

    Why monitoring alone leaves a blind spot

    Tool access is not data permission

    An agent may be correctly authorised to query an ERP and still send more data than the task requires. Least-privilege access to a tool does not automatically create least-data disclosure inside each request.

    Prompt controls do not cover retrieval and output

    Sensitive content can enter through a RAG chunk or a tool response rather than the user's prompt. It can also appear in the model output. Controls therefore need to cover the full path, not only the initial message.

    An incident record is not preventive control

    Logs are essential evidence, but discovering an exposure after transmission is different from stopping it. Regulated workflows need both: inline enforcement to reduce risk and a traceable record to demonstrate what happened.

    A practical governance architecture

    Place a provider-neutral policy layer between enterprise applications or agents and the models they use. Route every interaction through the same sequence: detect, decide, protect, send, inspect and log. Reversible values belong in an encrypted token vault and should only be revealed through controlled, audited access. Organisation boundaries must remain strict throughout the flow.

    This complements agent inventory and performance management rather than replacing them. Together they answer both sides of governance: whether an agent should keep running, and whether each interaction respects the organisation's data policy while it runs.

    What security teams should ask next

    • Can we identify the sensitive data used in every agent interaction?
    • Are policies enforced before data reaches any model provider?
    • Do the same controls cover prompts, RAG context, tool results and outputs?
    • Can tokenized values be revealed only by authorised users with an audit trail?
    • Can we export evidence by agent, organisation, policy and provider?

    See how Privaro applies these controls in the AI agents use case, review the enterprise AI security architecture or explore the API reference.