Leadership1 publisher3 min readPublished
Trust3 AI's co-founder puts four runtime agent controls outside the governance committee's remit
Neeraj Sabharwal's Forbes Tech Council argument separates prompt injection, tool scope, rollback and runtime monitoring from the policy work boards already fund, and it arrives without a single incidence figure.
The Board Room · Leadership desk
What happened
- Neeraj Sabharwal, co-founder of Trust3 AI, argued in a Forbes Tech Council piece that AI governance and agent security are separate disciplines and that neither one covers the other.
- In his invoice-processing example, governance never asks what happens if a prompt injection inside an invoice PDF instructs the agent to route payments to a different account.
- He called the common practice of deferring agent security until deployments mature a strategic error, on the grounds that the attack surface is already live.
Compiled by The Board RoomSomething wrong?How this is made
Why it matters
- decision Someone has to be named as the owner of tool-level privilege and rollback before an agent gets write access, and on this account that owner is not the committee that signed the responsible-AI policy.
- constraint Controls built for audit cycles cannot see an action taken in the moment, so a board attestation covering the model says nothing about what the running agent did at 3am.
- exposure The reachable surface is defined by the tools an agent holds. A wire transfer or a record deletion is the point where reversibility stops being a design question.
- contradiction The argument is coherent but comes from a vendor in the agent-trust market and carries no incidence data, so it can tell a board where to look and not how large the exposure is.
The two questions differ in tense. Governance, as Sabharwal frames it, asks "How should AI be developed, deployed and monitored to ensure responsible, ethical and compliant outcomes?" [6] That is answerable in a document, before deployment and again at audit. Agent security asks "Given that an AI agent is executing autonomous actions across enterprise systems, how do we ensure it cannot be exploited, manipulated or compromised?" [7] That one only has an answer while the agent is running.
The lists he gives for each do not intersect. Governance covers policy and accountability, bias and fairness, transparency and explainability, regulatory compliance under GDPR, the EU AI Act and HIPAA, data stewardship, and model lifecycle management [8]. Agent security covers prompt injection defence, tool and API boundary enforcement, action verification and rollback, and runtime monitoring with anomaly detection [9]. Six items against four, with each item on one list only [19].
Ownership is where the conflation happens. Both disciplines sit under the same leadership umbrella in many organisations, Sabharwal wrote, and his answer to that is one line: "But proximity is not equivalence." [4] [16] The committee that owns bias and fairness is not the function that enforces least privilege at the tool level [11]. He also wrote that "The frameworks have not kept pace with the architecture." [5]
His worked example is a supplier invoice agent, and it is hypothetical. Governance asks whether the model is free of bias, whether there is an audit trail, and whether the vendor is compliant with data regulations [14]. It does not ask what happens when a malicious actor embeds a prompt injection inside an invoice PDF telling the agent to route payments to a different account, what limits exist on that agent's access to other financial systems, or whether an unauthorised action can be detected and reversed [15]. Sabharwal classes prompt injection as an attack vector [10].
The boundary is being drawn by someone with a product on one side of it. Sabharwal is co-founder of Trust3 AI, and the piece is a Forbes Tech Council contribution [1] [2]. The invoice question does not depend on his company: either your charter names an owner for tool-level scope and rollback, or it does not. The piece cannot size the problem, because it carries no incidence count [20].
The sequencing claim is the part with a date attached. Many enterprises treat agent security as something to handle once deployments mature, and Sabharwal called that a strategic error on the grounds that the attack surface is live now [17]. The test for this quarter is narrower than the argument: whether any agent already holds authority to send a wire transfer or delete records [12]. In that case, verification and reversibility stop being theoretical. Runtime monitoring is continuous behavioural monitoring, and he distinguishes it from model evaluation for that reason [13]. Governance work is increasingly mandated by law [21]; regulatory compliance appears in his governance list and nowhere in his security list [8] [9].
What to watch
- A published count of production agents holding write access to payment or record-deletion systems would let a board size a gap this argument only describes.
- A disclosed incident in which a prompt injection inside a supplier document moved money would turn the invoice scenario from hypothetical into evidence.
- Governance charters that name an owner for tool scope, action verification and rollback would make the two-owner split visible in the org chart.