Who's governing your AI? A trust framework for enterprise agents and models

Experienced IT leaders know that shadow IT is a persistent problem, but rapidly evolving AI and the proliferation of agents mean the potential threat - and cost - is greater than ever. AI agents are non-deterministic, autonomous, and adaptable. They excel at solving tasks in creative ways, often to the surprise of their creators. We've seen agents write blogs that criticize project maintainers that refused their pull requests. Another one hacked a McKinsey chatbot to gain read/write access without asking for permission. And agents are getting smarter all the time. As an industry veteran, DigiCert's senior vice president of product Brian Trzupek sees an old pattern. "When the promise of the technology is so good, people are willing to throw security out the window, and they just want to get to that promise real fast." CISOs should be worried about allowing these agents into their infrastructure without strict controls, but it's happening anyway. IBM's 2026 Cost of a Data Breach report found that more organizations lacked governance to manage AI or detect shadow AI, at 68 percent compared to 63 percent last year. The number requiring IT approval to deploy AI had fallen to 38 percent from 45 percent. DigiCert is trying to solve this problem with its own approach to AI governance called AI Trust. The framework, outlined in this white paper, builds on what the company is good at: public key infrastructure, DNS, and attestation. The AI governance questions CISOs should ask AI Trust uses these tools to help organizations answer five AI governance questions: · What agents your employees are using · What regulated data is flowing to them · Whose credentials they hold · Whether a compromised agent can be stopped immediately · Whether an incident can be reconstructed with a tamper-evident trail Almost every enterprise fails at the first hurdle, warns Trzupek. Developers build agents or buy them from vendors and deploy them internally without asking. Users might also spawn agents from inside tools like Claude Desktop or OpenAI Codex that will then create sub-agents. "Those sub-agents don't assume the same rights and responsibilities and authorization as the parent agent," he says. "So they try to delegate tasks that can be wholly controlled." How to manage AI agent identity Most companies haven't developed the tools to keep track of all these different agent types yet. The first step is to identify them. This is where many organizations make their first mistake by bolting agents onto the human identity and access management (IAM) stack they already have. The idea is that if you give an agent a service account and a long-lived API key you can treat them like a super-fast employee. That's impractical. "IAM was built for a human sitting at a keyboard who can tap 'approve' on their phone," Trzupek says. "An agent can't do that. So you fall back to a static API key that never expires and has way more scope than it needs, and now you've undone everything zero trust was supposed to give you. It's the exact credential we've spent a decade telling people to get rid of." Industry bodies have started converging on a different answer. IDC now recommends treating agent identity as a workload identity problem rather than an extension of human IAM, aligning with the IETF's Workload Identity Management and Security Extensions (WIMSE) and NIST's Cybersecurity Framework version 2.0. They can then frame agents as governed workloads requiring runtime attestation and short-lived credentials . This idea also pushes teams toward the Service Profile Identity (SPIFFE) and its SPIFFE Registration Endpoint (SPIRE). This is an open workload identity standard already deployed inside many hyperscaler-hosted Kubernetes estates, and they're part of DigiCert's AI strategy. DNS is a governance tool for agentic AI Inventory and identity might get you visibility, but you still need somewhere to enforce policy. DigiCert has strong opinions about where, tied to its history managing DNS integrity. No matter whether an agent is resolving an API endpoint or connecting to an MCP server, it has to query DNS first. So why not make that a core verification point? DigiCert proposes a solution that looks a lot like the DMARC standard used for email. An organization would publish an agent policy record in DNS that declares several things: · Its authorized agent identities · The certificate authority that issued their credentials · The scopes they're allowed to act within A gateway can then query that record to verify whether an inbound agent is legit, and terminate the session if the check fails . And if an agent contacts an unauthorized domain mid-execution, DNS can block the query and the MCP gateway kills the session. IDC likes this idea but warns that scale is an issue. As the number of agents grows, DNS records might not keep up, and stale records might become a loophole. Overly permissive scope declarations are also still a potential problem. "The scale problem is real, but it's the same problem DNS has solved a hundred times before," Trzupek responds. "You automate the lifecycle, you tie the record to the certificate issuance, and when the cert expires the record goes with it." And operators writing wildcard scopes because they're in a hurry is a discipline problem, not an architecture problem, he adds. Inside DigiCert's AI Passport Agents built in-house live alongside third-party agents like Microsoft Copilot, Salesforce Agentforce and ServiceNow, and the control planes for the two categories are different. DigiCert's answer is a single SPIRE server anchored to a DigiCert CA for identity, with policy enforced centrally in an Open Policy Agent engine, and a unified kill switch that operates across both categories. The AI Agent Passport is the artifact that ties the identity to the authorization. It's a cryptographically protected record of approved systems and permitted operations. Each 'passport' also contains things like data sensitivity classifications and expiration state, along with an accountable human owner. Trzupek says the field that generates the most pushback in the design is policy itself, because customers typically have a complex web of policies already in GCP or AWS. "Trying to replace those or displace them is a fool's errand," he says. So the passport can hold pointers to those engines rather than replacing them. How to manage model integrity Governing agents is only half of the challenge. The models themselves are strategic assets, and they're subject to integrity and provenance controls too. That means encryption and cryptographic signing of model artifacts, Open Container Initiative-compliant packaging with tools like the Sigstore code signing initiative, and a cryptographically verifiable Model bill of materials describing weights, datasets and dependencies . It also means governing models at runtime, not just securing the supply chain. DigiCert's AI Trust framework advocates trusted hardware execution to help solve that problem. A model running inside a trusted execution environment on Intel TDX or AMD SEV-SNP stays encrypted in memory, isolated from the host OS. DigiCert operates a confidential computing attestation service that follows the IETF Remote ATtestation Procedures (RATS) architecture. The execution environment is the attester and DigiCert is the verifier. Downstream systems are the relying parties. This approach moves attestation from a neutral third party rather than the cloud operator running the workload, which serves regulated buyers. Hyperscalers shouldn't attest to their own integrity. Those regulated buyers face some heavy governance conversations. In healthcare, the question is whether the AI model cleared through an FDA 510(k) pathway is the exact algorithm running in clinical deployment. Cryptographic attestation lets these companies prove model integrity before every inference. That addresses the FDA's 2023 cybersecurity guidance on software integrity verification and SBOM enforcement. But while some regulated verticals have specific needs, AI governance is a cross-sector problem. Any organization storing customer data an agent can access or exfiltrate needs these controls. Why build in AI governance now This is agentic AI's moment, so companies are at a pivot point, and they've been here before. Many of them spent the last 25 years following a cybersecurity antipattern: move fast to grab an opportunity with a significant new technology development, and call in the security team later to clean up the loose ends. It hasn't gone well. With many organizations at the beginning of their agentic AI journey, they now have an opportunity to break that habit and do things right from the beginning using verifiable controls. As frontier model prices climb and AI crops up as a noticeable cost on enterprise budgets, this will become an increasingly visible choice, concludes Trzupek. Companies will hold people more accountable for their use of agentic technology. Wouldn't it be nice to have the controls in place and be ahead of the game for once? Sponsored by DigiCert