{"slug":"okta-data-ai-agents-still-log-in-as-humans-breaking-the-audit-trail","citations":[{"url":"https://www.kiteworks.com/cybersecurity-risk-management/ai-agents-identity-audit-trail/","committed_hash":"sha256:be3c89845ddefc6c484e14cb3ef571d31b6fa51b89badfa912147a392128e385","committed_hash_short":"sha256:be3c8984…2128e385","mime_type":"text/html","committed_at":"2026-07-27T12:00:26.792041+00:00","content_snapshot":" AI Agents Logging In as Humans Break Audit Trails
AI Agents Are Still Logging In as Humans – and Your Audit Trail Is Paying for It
by Patrick Spencerupdated July 21, 2026Cybersecurity Risk Management
Reading Time: 12 minutes
Enterprises have spent the last four years bolting AI agents onto identity infrastructure that was never designed to recognize them as distinct actors. That mismatch is now visible in the data, not just in incident postmortems. A new report built on anonymized sign-on activity from more than 20,000 organizations shows AI agents operating inside enterprise environments largely the same way they did when generative AI first arrived: authenticated as, or through, a human.
The report is the Okta Enterprise AI Index, and it draws on sign-on data spanning June 2022 through June 2026 across more than 100 distinct AI products, consolidated into 74 vendor suites for analysis. The scale of the dataset is what makes the finding hard to dismiss as an edge case. This is not a story about one vendor’s misconfiguration or one company’s rushed AI rollout. It’s a pattern across tens of thousands of organizations that are choosing, or simply defaulting into, the same way of authorizing AI agent workflows.
The headline growth numbers are dramatic. AI-native companies such as Anthropic, OpenAI, and Cursor more than quadrupled their enterprise customer base over the study period, and Anthropic passed OpenAI in total enterprise accounts in March 2026, then overtook it in monthly active users the following month. Those milestones say something real about how quickly agentic AI has moved from experimentation to standard enterprise tooling. But the more consequential finding sits underneath the growth curve: identity and access practices for AI agents have not kept pace with how fast those agents are being deployed.
Kiteworks secure data exchange was built around a different premise: every actor touching sensitive content, whether human or machine, needs a verifiable identity, scoped permissions, and its own entry in the audit trail. That premise is exactly what this report finds missing in most enterprise AI deployments today.
Key Takeaways
1. Enterprise AI adoption has outrun enterprise identity practices.
New sign-on data covering four years and more than 20,000 organizations shows AI-native vendors growing enterprise accounts more than 4x, while the identity model behind those tools has barely changed since the pilot-project era.
2. Agents still borrow human credentials.
Service accounts, static API keys, and shared human logins remain the default way organizations authorize AI agent workflows, according to Okta researcher Fei Liu, and each of those methods was built for a world without autonomous software actors.
3. A borrowed login means a broken audit trail.
When an AI agent authenticates as a person, logs show that person’s name attached to actions the person never took, which makes it nearly impossible to reconstruct what an agent actually did during an incident review.
4. The Anthropic-OpenAI enterprise race is a symptom, not the story.
Anthropic overtaking OpenAI in enterprise accounts and monthly active users in early 2026 confirms how fast agentic AI is moving into core business workflows, faster than most identity and access programs have adapted to govern it.
5. Agent-scoped access control closes the gap.
Assigning each AI agent its own governed identity, permissions, and audit record, rather than routing it through a human’s session, is the difference between a governable AI deployment and an ungoverned one.
You Trust Your Organization is Secure. But Can You Verify It?
Service Accounts, Static API Keys, and Shared Logins: Three Ways Agent Identity Breaks Down
According to Fei Liu, the Okta researcher quoted in the report, organizations rely heavily on three mechanisms to authorize AI agent workflows: service accounts, static API keys, and, in some cases, shared human logins. Each solves a short-term integration problem. Each also creates a longer-term governance problem that most organizations have not yet reckoned with.
Service accounts are the most common of the three. They let an AI agent act as a designated non-human identity within an application, which sounds like the right approach until you look at how those accounts are usually provisioned and monitored. Many service accounts are created once, granted broad access controls to satisfy whatever the agent might eventually need to do, and then left alone. Nobody revisits the permissions as the agent’s role expands. Nobody ties individual actions back to a specific task, request, or business justification. The account exists, the agent uses it, and the resulting logs describe the account rather than the work. Applying data classification labels to the content service accounts can access is the prerequisite that makes access scoping precise — without it, a governance program cannot enforce sensitivity-based restrictions on what an agent reaches through that account.
Static API keys carry a related set of problems, compounded by how they’re handled operationally. A key that authorizes an agent to read files, query a database, or call an internal system typically doesn’t expire, doesn’t rotate automatically, and often gets copied into configuration files, environment variables, or, worse, directly into a prompt or agent context window where it can be exposed, logged, or exfiltrated without anyone noticing. Once that key exists in more than one place, “who has access” stops being a question anyone can answer with confidence.
The third pattern, shared human logins, is the most concerning because it collapses the distinction between person and process entirely. An employee’s credentials get handed to an automation script, a bot, or an AI agent so it can act “as” that person inside a system that has no separate provisioning path for machine identities. From that point forward, every action the agent takes shows up in logs as if the human performed it. A confirmed data breach routed through a shared human login that an agent used leaves organizations unable to scope the breach accurately — notification obligations under HIPAA, GDPR, or comparable frameworks apply to the maximum possible exposure unless affirmative evidence narrows it, evidence that a mixed human-agent audit trail cannot provide.
Why “When an AI Agent Inherits a Human’s Login, You Lose the Audit Trail” Should Worry Every CISO
Liu’s warning in the report is direct: “when an AI agent inherits a human’s login, you completely lose your audit trail.” That sentence describes a specific, mechanical failure, not a vague risk. An audit trail is only useful if it can tell you, after the fact, who did what, when, and why. Once an agent is acting under a human’s session, that trail records the wrong actor for every single event. The name in the log is correct. The story it tells is not.
This matters most in the moments an audit trail is actually needed: a breach investigation, a compliance audit, a regulatory inquiry, or an internal review of how a piece of sensitive content moved through the organization. In each of those scenarios, someone eventually asks a version of the same question: did a person do this, or did an automated process do this, and under what authority? If the answer is “we can’t tell, because the agent was logged in as Sarah,” the investigation stalls, the compliance response weakens, and the organization can’t demonstrate the kind of access controls that frameworks such as NIST CSF, ISO 27001, and SOC 2 all expect as a baseline. Feeding a clean, agent-attributed audit log in real time into a SIEM platform is the operational mechanism that converts agent attribution from a forensic tool reviewed post-incident into a behavioral detection layer that surfaces anomalous agent activity before a breach event completes.
There’s also a quieter cost that shows up long before any incident: accountability erodes gradually, in the ordinary course of business. When nobody can say with certainty which actions were taken by a person and which were taken by an agent, exception approvals, data access reviews, and least-privilege enforcement all get harder to run correctly. Reviewers start approving broad access because narrowing it feels risky when they can’t isolate what the agent specifically needs. That’s how security misconfiguration compounds over time, not through one bad decision but through many reasonable-seeming ones stacked on top of an identity model that was never built to separate humans from the software acting on their behalf.
Shadow AI Is an Identity Problem Before It’s a Data Problem
Most conversations about shadow AI focus on where sensitive data ends up: an unsanctioned model, an unapproved plugin, a browser extension nobody vetted. That’s a real concern, but the Okta data points at something upstream of it. Before an agent can move or expose data, it has to authenticate somewhere. If that authentication step routes through a shared account, an unmanaged API key, or a borrowed login, the organization has already lost visibility before the data governance question even comes up.
This is why identity deserves top billing in any AI governance conversation, not a footnote under data loss prevention. An agent with a scoped, well-managed identity is constrained by design: it can only reach what its role permits, and every action it takes is attributable to that specific agent and task. An agent operating under a human’s session or a broadly-provisioned service account isn’t meaningfully constrained at all; its actual reach depends on whatever that human or that account happens to have access to, which is often far more than the agent’s task requires. AI data governance programs that start with policy documents but skip identity architecture are solving the easier half of the problem. Shadow AI — agents and AI tools operating outside any sanctioned identity program — is the direct consequence of that gap: ungoverned agents that the organization cannot see, cannot scope, and cannot attribute actions to when an incident surfaces.
The Kiteworks 2026 Data Security and Compliance Risk: Annual Forecast Report identifies AI governance as one of the defining data security priorities organizations face this year. The Okta findings reinforce that conclusion from a different angle: agentic tools have been adopted faster than the zero trust identity and access controls needed to govern them. Supply chain risk management programs that extend identity governance requirements to third-party AI vendors — covering the agents those vendors deploy inside customer environments, not only the tools customers deploy themselves — close the supply chain identity gap that the Okta data suggests most organizations have not yet scoped.
How Kiteworks Gives Every AI Agent Its Own Verifiable Identity
Kiteworks approaches this problem from the same starting point the Okta findings point to: humans and AI agents are both first-class identities that need to be authenticated, authorized, and logged individually, under one governance layer rather than two separate ones. The Kiteworks Control Plane governs every request for sensitive content, whether it comes from a person, an application, or an agent, through that single model, so an agent’s access is never routed through a workaround like a borrowed human credential or an unmanaged service account.
The Secure MCP Server is the piece purpose-built for this moment. It authenticates through OAuth 2.0, with the access token stored in the operating system’s secure credential store rather than anywhere the AI model itself can read, copy, or leak it. That is a meaningfully different design than handing an agent a static API key or a shared human password: the agent never holds a credential it could expose through a prompt, a log file, or a compromised session. Every operation the agent performs, whether reading a file, navigating a folder, or retrieving content for a task, is evaluated against RBAC and ABAC policy in real time and logged on its own terms, rather than folded into a single, generic entry that simply says a person did it. That is the structural answer to Fei Liu’s warning: when the credential never leaves a secured store and every action is authorized and logged individually, there is no shared identity for the audit trail to lose track of. The CISO Dashboard surfaces this agent-level audit telemetry in real time, giving security leadership the unified visibility across all AI-mediated content access events that the Okta report identifies as missing from most current deployments.
Kiteworks Compliant AI applies that same discipline to what agents can see and use, not just how they authenticate. Content-level policy enforcement determines what an agent is permitted to access or withhold before the content ever reaches the model’s context window, so the identity boundary and the data boundary reinforce each other instead of one depending entirely on the other holding. Data minimization applied at this layer — ensuring each agent receives only the minimum content its current task requires — reduces blast radius when an agent credential is exposed, since the agent’s accessible scope is already constrained by design.
Building an Agent-Scoped Access Control Model with RBAC and ABAC
Solving the identity gap means moving beyond “does this agent have a credential” to “does this specific agent, for this specific task, have the specific permission it needs right now.” That’s a role- and attribute-based question, not a static provisioning question.
Role-based access control (RBAC) gives each agent a defined role scoped to its actual function. Consider a summarization agent that only needs read access to the documents it summarizes, or a workflow agent that files records and needs write access to one specific folder, and nothing more in either case. Attribute-based access control (ABAC) adds context to that role: the sensitivity classification of the content, the time of the request, the agent’s deployment environment, and the task it’s currently executing all factor into whether a given request is authorized. Together, RBAC and ABAC let an organization grant an agent exactly the access its current task requires and nothing it might need someday, which is the opposite of how most service accounts are provisioned today.
This model also produces something the Okta report highlights as missing: a clean audit log where every entry names an actual agent, tied to an actual task, evaluated against an actual policy, not a person’s name standing in for work they never did. When an incident review or compliance audit asks what happened, the answer is already in the log, attributed correctly the first time. A documented incident response plan that covers AI agent misfire scenarios — specifically the steps for isolating a compromised agent identity, revoking its credentials, and scoping what content it accessed — converts the clean audit log from a forensic asset into an operational response capability.
What Enterprises Should Do Now to Close the AI Agent Identity Gap
The scale of the Okta dataset (four years, 20,000-plus organizations, over 100 AI products) makes clear this isn’t a problem confined to early adopters or laggards. It’s close to universal, which means most security and identity teams have work to do regardless of how mature their AI governance program already is.
A few starting points follow directly from the report’s findings. First, inventory every AI agent currently operating in the environment and identify exactly which credential each one uses: service account, API key, or human login. You can’t fix what you haven’t mapped. Second, treat any agent authenticating through a shared human login as an immediate priority for remediation, since that pattern produces the most severe audit trail loss described in the report. Third, evaluate whether your current IAM infrastructure can actually provision distinct, scoped identities for non-human actors, or whether it was built with only people in mind. Fourth, build agent access decisions around zero trust data exchange principles: verify every request, grant the minimum necessary access, and log the outcome, rather than trusting an agent by virtue of the account it happens to run under. A formal risk assessment that maps each agent’s current credential type and permissions against its actual task requirements — and identifies where shared credentials or over-provisioned service accounts create unacceptable exposure — is the evidentiary foundation for a prioritized remediation roadmap.
None of this requires waiting for a breach to justify the work. The Okta data describes a structural gap in how enterprises authorize AI agents today, not a hypothetical future risk. Closing it now, while agentic AI adoption is still accelerating, is considerably cheaper than reconstructing an audit trail after the fact discovers it never existed.
To learn more about giving AI agents their own governed identity instead of borrowed human credentials, schedule a custom demo today.
Frequently Asked Questions
The Okta Enterprise AI Index is a report built from anonymized sign-on data spanning more than 20,000 organizations from June 2022 through June 2026, covering over 100 distinct AI products consolidated into 74 vendor suites. It tracks how enterprises adopt AI tools and, notably, how those tools are authenticated and authorized within corporate environments. The report found that AI agents are still commonly authorized through service accounts, static API keys, or shared human logins rather than through identities scoped specifically to the agent. Organizations evaluating their own exposure to this pattern can start by reviewing how their IAM infrastructure currently provisions non-human actors. Those subject to regulatory compliance obligations — HIPAA, GDPR, CMMC — should treat the authentication gap the Okta report documents as a compliance finding, since these frameworks require demonstrable access controls and audit records regardless of whether the accessor is a human or an agent.
A service account is typically provisioned once with broad permissions meant to cover whatever the agent might eventually need, then rarely revisited. That means the agent often has far more access than its current task requires, and every action it takes gets attributed to the account rather than to a specific, traceable task. This breaks the principle of least privilege and weakens the access controls that compliance frameworks expect organizations to maintain. Agent-scoped identities, by contrast, can be limited to exactly what a given task requires. Data minimization applied to service account scope — provisioning each agent with access only to the specific data sources its designated task requires — is the operational practice that converts least-privilege from a policy intent into a runtime reality.
When an AI agent authenticates using a person’s credentials, every action it performs gets logged under that person’s identity, even though the person never took those actions. This makes it functionally impossible to distinguish human activity from agent activity during a security investigation, compliance audit, or incident response process. Fei Liu of Okta describes this precisely: once an agent inherits a human login, the audit trail is lost because the record no longer reflects who or what actually did the work. Agent-scoped credentials prevent this by ensuring every log entry names the actual actor. Organizations should also verify that their SIEM alert configurations treat anomalous patterns in agent-attributed log entries — unexpected access times, unusual data volumes, or out-of-scope resource requests — as high-priority detection signals rather than background noise.
The Secure MCP Server is Kiteworks’ governed connection point for AI agents using the Model Context Protocol to access enterprise content. Rather than issuing an agent a static credential it can hold or expose, it authenticates through OAuth 2.0 with the token stored in the operating system’s secure credential store, and it evaluates every request against RBAC and ABAC policy in real time. This keeps credentials out of the agent’s reach entirely, which is the specific failure mode the Okta report describes when agents inherit human logins. Data classification applied to the content the Secure MCP Server governs makes ABAC enforcement precise — access decisions can distinguish between public-tier and confidential-tier content at the moment of each agent request, rather than applying a single blanket permission to the agent’s entire accessible scope.
Not necessarily. The more urgent step is provisioning AI agents as their own class of governed identity, alongside human users and under the same policies, rather than routing agents through human sessions or generic service accounts as a workaround. Kiteworks does this through the Kiteworks Control Plane, which governs access, use, and exchange of sensitive content for both humans and agents under one set of policies, combined with RBAC and ABAC controls scoped to each agent’s actual task. A risk assessment that maps which agents currently operate through shared credentials — and prioritizes remediation by the sensitivity of the content those credentials can access — gives identity and security teams the focused starting point that makes agent identity remediation tractable rather than overwhelming.
It’s easy to start ensuring regulatory compliance and effectively managing risk with Kiteworks. Join the thousands of organizations who are confident in how they exchange private data between people, machines, and systems. Get started today.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
On August 2, 2026 — two months out as I write this — the EU AI Act's high-risk obligations under Annex III reach full enforcement. If your organization deploys AI agents that influence decisions in a high-risk category (employment, lending, healthcare, essential services, law enforcement, critical infrastructure), a set of concrete technical requirements becomes legally binding.
\n\n
The one this article is about is Article 12: high-risk AI systems must technically allow \"automatic recording of events (logs) over the lifetime of the system.\" Automated logs retained for at least six months. Article 99 backs it with fines up to €35 million or 7% of global turnover for the most serious violations.
\n\n
One important accuracy note before we go further: a proposed extension of these deadlines to December 2027, via the EU Digital Omnibus, was under negotiation as of April 2026. As of this writing it has not become law. You cannot plan engineering work around an extension that doesn't legally exist. Build for August 2.
\n\n
A second accuracy note: whether your specific AI coding agent falls under high-risk obligations depends on what it's deployed to do, not on the fact that it's an AI agent. An agent writing a CRUD app for an internal tool is in a different position from an agent operating in or building systems for a regulated decision domain. But the audit-trail capability is worth building regardless, because — as the rest of this article argues — enterprise procurement and SOC 2 increasingly demand the same record even outside EU AI Act scope, and building it after you need it is the expensive path.
\"Keep logs\" is not the requirement. Everyone keeps logs. The requirement, as the 2026 compliance guidance consistently frames it, is traceability. You must be able to prove why an agent took a specific action, what data it used, and what governance policies were applied at the moment of execution.
\n\n
\n \n \n Why most agent deployments produce neither record\n
\n\n
Most teams are logging prompts and completions. That is a record of intent and response, but it is not a record of governance.
\n\n
If you have a middle layer that checks an agent's proposed tool-call against a policy (e.g., \"Don't let the support agent refund more than $50 without a manager signature\"), that check is the most important piece of the audit trail.
In the 2026 landscape, you cannot separate the act of enforcing a policy from the act of auditing it. If your governance layer is a separate \"observer\" that looks at logs after the fact, you are already out of compliance for high-risk systems. You need Runtime Governance.
Let's be clear: adding a governance gate adds latency. In the \"old\" days of 2024, we cared about every millisecond of TTFT (Time to First Token). In the compliance-first world of 2026, we trade 50ms of latency for the legal right to operate the system.
The \"enforcement and audit are the same act\" collapse is the right one, and Leo's point about who can verify the record is the necessary second half. One more field that belongs in that gate-written entry, beyond the permit/deny verdict: the gate's strength at decision time — was it hard (block and fail-closed) or soft (warn and proceed)? Two deployments can emit byte-identical action logs and sit miles apart on Article 12's \"what governance policies were applied at the moment of execution,\" because one actually blocked and the other only annotated. If enforceability isn't its own recorded field, a reviewer has to reconstruct it from outcomes after the fact — exactly the posture the article argues against. So the entry that's worth signing is verdict + gate-strength + the policy id that fired, together: it makes the gate's bindingness checkable rather than inferable.
\n Seasoned Android engineer and AI specialist with 15+ years of software development experience and a deep focus on native Android. Proven track record modernizing high-traffic apps using Kotlin.\n
This is the right next field. Hard vs soft at decision time is exactly the difference Article 12 reviewers care about, and you're right that byte-identical action logs hide it.
\n\n
We've started treating the signed entry as a triple:
\n\n
\n
verdict (permit / deny)
\n
gate_strength (hard/fail-closed vs soft/warn-and-proceed)
\n
policy_id that fired
\n
\n\n
Without gate_strength as a first-class recorded field, enforceability becomes an after-the-fact inference — the posture the post argues against. Appreciate you pushing the schema one step further than the article did.
Strong agreement on “enforcement and audit are the same act.”
\n\n
The gate that decides is the only thing positioned to record why. That collapses the observer after the fact model cleanly.
\n\n
One dimension I’d add is where the tamper evident record lives, and who can verify it. A gate that writes its own audit is necessary, but not sufficient. If the record sits server side with the same vendor running the agent, then the vendor is effectively attesting to its own behavior. For a regulator or enterprise buyer, that is weaker than independent evidence.
\n\n
The stronger version is a record that can be verified without trusting the party that produced it and, if needed, verified against it.
\n\n
That pushed me toward enforcing at a local proxy boundary rather than a hosted gate. Same enforcement is audit principle, but the hash chain stays local and can be verified cross language by a small independent walker with nothing from us installed. The evidence survives the vendor.
\n\n
I built this as a small open source tool: Occasio, a local first policy gate, human approval layer, and verifiable audit trail for AI coding agents. Not affiliated with any provider.
\n\n
The “50ms for the legal right to operate” framing is exactly right, and underrated.
\n Seasoned Android engineer and AI specialist with 15+ years of software development experience and a deep focus on native Android. Proven track record modernizing high-traffic apps using Kotlin.\n
This is the dimension I underweighted in the original post. A gate that writes its own audit is necessary but not sufficient if the same vendor that runs the agent also holds the only copy of the record.
\n\n
Independent verifiability — a tamper-evident log a regulator or buyer can check without trusting the producer — is the stronger bar. Local/append-only export, hash-chained entries, and (when needed) a third-party or buyer-controlled sink are the practical shapes we've been dogfooding. Appreciate you making that half of the argument explicit.
\n\n\n
\n\n
\n\n \n\n \n\n
\n\n\n\n \n \n\n\n \n \n\n\n \n \n\n
\n\n
\n Some comments may only be visible to logged-in visitors. Sign in to view all comments.\n \n
\n\n \n\n
\n\n\n
\n
For further actions, you may consider blocking this person and/or reporting abuse
![\"Kiteworks](\"https://www.kiteworks.com/wp-content/uploads/2026/07/kiteworks-logo-1.svg\"){kind=logo}
![\"AI](\"https://www.kiteworks.com/wp-content/uploads/2026/07/bannerbear-ai-agents-identity-audit-trail-840x390.jpg\")
![\"DEV](\"https://media2.dev.to/dynamic/image/quality=100/https://dev-to-uploads.s3.amazonaws.com/uploads/logos/resized_logo_UQww2soKuUsjaOGNB38o.png\"\n){kind=logo}
\n![\"Igor](\"https://media2.dev.to/dynamic/image/width=50,height=50,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F63190%2Fa3e089af-f0e9-4fa7-8d8c-e35f7a82bae0.jpg\")
![](\"https://assets.dev.to/assets/sparkle-heart-5f9bee3767e18deb1bb725290cb151c25234768a0e9a2bd39370c382d02920cf.svg\")
![](\"https://assets.dev.to/assets/multi-unicorn-b44d6f8c23cdd00964192bedc38af3e82463978aa611b4365bd33a0f1f4f3e97.svg\")
![](\"https://assets.dev.to/assets/exploding-head-daceb38d627e6ae9b730f36a1e390fca556a4289d5a41abb2c35068ad3e2c4b5.svg\")
![](\"https://assets.dev.to/assets/raised-hands-74b2099fd66a39f2d7eed9305ee0f4553df0eb7b4f11b01b6b1b499973048fe5.svg\")
![](\"https://assets.dev.to/assets/fire-f60e7a582391810302117f987b22a8ef04a2fe0df7e3258a5f49332df1cec71e.svg\")
![\"\"](\"https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F63190%2Fa3e089af-f0e9-4fa7-8d8c-e35f7a82bae0.jpg\")
\n ![\"lbrauer](\"https://media2.dev.to/dynamic/image/width=50,height=50,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3927459%2F4cde7ee2-5750-4cb5-b1b7-f43ee9456603.png\")
\n ![\"\"](\"https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3927459%2F4cde7ee2-5750-4cb5-b1b7-f43ee9456603.png\")
\n ![\"DEV](\"https://media2.dev.to/dynamic/image/width=190,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F8j7kvp660rqzt99zui8e.png\"\n)
\n
\n \n \n\n \n\n \n \n
\n\n- \n
\n Joined\n \n \n \n \n \n
\n\n- Copy link
\n \n - \n
\n Hide\n \n \n \n \n \n
\nThe \"enforcement and audit are the same act\" collapse is the right one, and Leo's point about who can verify the record is the necessary second half. One more field that belongs in that gate-written entry, beyond the permit/deny verdict: the gate's strength at decision time — was it hard (block and fail-closed) or soft (warn and proceed)? Two deployments can emit byte-identical action logs and sit miles apart on Article 12's \"what governance policies were applied at the moment of execution,\" because one actually blocked and the other only annotated. If enforceability isn't its own recorded field, a reviewer has to reconstruct it from outcomes after the fact — exactly the posture the article argues against. So the entry that's worth signing is verdict + gate-strength + the policy id that fired, together: it makes the gate's bindingness checkable rather than inferable.
\n\n\n