The Agent Enterprise Is Here. The Authorization Layer Isn't.

ENFORCEAUTH TECHNICAL WHITE PAPER — INDUSTRY ANALYSIS

By Mark Rogge, CEO of EnforceAuth | 18 min read | for CISOs, security architects, and the CIO/CDAO who now owns AI risk

What 200 CISOs told Lightspeed and Fortune — read as a runtime authorization specification

The 90-second version, for the CIO or CDAO who now owns AI risk

Your agents are in production (77%). You cannot list all of them (only 20% can). A quarter of them act with a human's credentials, so your logs cannot tell agent from employee. Your top AI threat is one of your own agents, hijacked, doing something legitimate-looking with permissions it already holds. Most of your AI incidents this year were suspected, not confirmed, because the evidence to confirm them does not exist. And your security team already lets AI act with no human approval, and told Lightspeed it will let it do more once it gets scoped permissions, audit logs and rollback.

Every one of those is the same gap: nothing decides, per action, whether this agent may do this thing to this record right now, and nothing records why. That is runtime authorization. It is the #1 category your CISO will evaluate in 2027 whether or not you fund it. This paper is the technical case for funding it first.

Executive summary

On October 28, 2026, Lightspeed Venture Partners and Fortune published the fourth annual Cyber60 report with a Wakefield Research survey of 200 U.S. CISOs at companies with $500M or more in revenue. The headline is adoption: 77% of those companies have AI agents in production, 98% are at least piloting them, and 88% already let AI execute security response actions with no human approval.

The body of the report is something else. Read closely, it is a specification for a control most of these companies do not yet have. Only 20% of companies using or exploring agents keep a complete inventory. Only 34% select dedicated per-agent identities with scoped permissions as their current or intended approach; 26% pass human credentials to agents and 15% use shared service accounts. Compromised or hijacked agents acting inside the environment now tie AI-generated phishing and deepfakes as the top AI threat at 51%. When CISOs were asked what it would take to let an agent act alone, they named accuracy, scoped permissions, audit logs and rollback. And when asked which tool category they will evaluate in the next 12 months, the top answer at 55% was agent identity, authorization and access governance, with runtime guardrails for agents third at 48%.

Those are not six separate findings. They are one finding stated six ways: enterprises have authenticated their agents, instructed their agents, and in many cases unleashed their agents, but they have not built the layer that decides, per action, whether the agent is allowed to do the specific thing it is about to do. That layer is runtime authorization. This paper reads the survey as the specification for it, shows the structural reason that identity governance, model guardrails and platform control planes each stop short of it, and sets out a reference architecture, a worked policy example, an implementation sequence and a 10-question self-assessment mapped to the survey.

Two honesty notes before the argument. The survey's margin of error is ±6.9 points and subgroup findings under n=100 are directional; where this paper cites a subgroup, treat it that way. And Lightspeed is explicit that its correlations (security leading governance, fewer incidents, higher confidence) do not establish causation. Neither does this paper.

1. The adoption numbers are not the story

The survey moved from asking about "AI" in 2025 to asking about agents in 2026, and the distinction matters. An LLM that answers questions has an output problem. An agent that calls tools has an action problem. Every figure in the report that should worry a security leader is an action figure.

Agents are in production at 77% of surveyed companies: 21% across multiple business functions, 56% in a limited set. Companies with security teams that are mostly or fully confident in their AI skills are further along (85% in production, versus 66% of less confident teams; directional). Only 2% have no agent initiative.

Set that against the control picture among the 196 respondents using or exploring agents. 94% keep some inventory, but only 20% call it complete; 74% are working from a partial list. The report's own line is the right one: security teams need to know which agents are operating before they can govern their access. Inventory is the precondition for every other control in this paper, and four in five companies do not have it.

Then authentication. 34% select dedicated per-agent identities with scoped permissions as their current or intended approach. 26% select human user credentials passed to agents. 15% select shared service accounts. 26% select a mix. Lightspeed partner Guru Chahal's reading is precise: human credentials "can give the agent the person's permissions and leave security teams struggling to tell who did what."

Here is the first place the survey is quietly asking for something it does not name. Even the 34% with scoped per-agent identities have answered only the question of who the agent is. A scoped identity is a static grant, decided at provisioning time. It does not know what the agent is about to do, on which record, in what state, under whose delegated authority, right now. None of the four authentication options on that chart answers that question, because authentication cannot. That is what authorization is for, and it is the layer the rest of the survey keeps circling.

2. The threat CISOs fear most is an authorization failure

The 2025 threat list was about AI as a weapon aimed at the enterprise: phishing, synthetic identities, LLM-written malware. The 2026 list is about AI as a weapon already inside it. Compromised or hijacked AI agents acting inside the environment tie AI-generated phishing and deepfakes at 51%. Ungoverned non-human identities and agent credentials are at 41%. The agent tool and integration supply chain (MCP servers, plugins, connectors) is at 40%. Prompt injection, the primary technique for hijacking an agent, is at 36%. Three of the top five concerns are agent concerns.

Be precise about what a hijacked agent is. In most of these incidents nobody breaks in. An agent that is legitimately provisioned, legitimately authenticated and legitimately running reads a document, an email, a web page or a tool result that contains instructions, and does something its operator never intended with permissions it already holds. The credentials are valid. The session is valid. The API calls are well-formed. Every control that checks who is calling passes.

That is why authorization, not authentication, is the control that bounds this threat. Runtime authorization does not prevent prompt injection; nothing at the action layer can stop a model from being persuaded. What it does is make persuasion insufficient. If the agent's authority to act is decided per action by a policy engine outside the model, then an injected instruction to export the customer table, change the payment destination, or delegate a task to a sub-agent with wider scope is evaluated against policy and denied, regardless of how convincing the instruction was. The blast radius of a hijacked agent becomes the set of actions policy would have allowed anyway, and that set is small by design.

A note on language, because it will matter to the legal and insurance teams that increasingly sit in the governance room. A hijacked agent that acts within its granted permissions has not, under most definitions, performed "unauthorized access." Nothing was bypassed. That is exactly the problem: the existing control vocabulary does not have a word for a legitimate principal doing an illegitimate thing. Runtime authorization gives it one, by making "authorized" mean "this action, under this policy, with this evidence," not "this identity, with this role."

3. The evidence problem hiding inside the incident numbers

79% of CISOs report a confirmed or suspected AI-related incident in the past 12 months, up from 75%, and 99% have at least detected AI-related attack attempts. The composition of that 79% changed sharply: confirmed incidents fell from 37% to 16%, while suspected-but-unconfirmed incidents rose from 38% to 63%.

There are two readings. The first is measurement: a year of AI-security attention may have made CISOs more willing to suspect AI involvement and more careful about confirming it, and the 2026 sample skews to smaller companies and smaller teams than 2025 (median security headcount fell from 50 to 35), so some of the shift may be sample composition rather than change. The second reading is the one Lightspeed partner Tal Morgenstern offered: it "raises a question about how well security teams can establish when AI was involved."

The paper's position is that the second reading is the one to act on, because under either reading the gap is the same. If you cannot distinguish an agent's actions from the human whose credentials it is using (the 26%), cannot enumerate which agents exist (the 80% without a complete inventory), and have no per-action record of what each was permitted to do and why, then you cannot confirm an AI incident. You can only suspect one. The survey's 63% is what a missing evidence layer looks like in aggregate.

This is where detection-centric thinking fails, and it is the gap EnforceAuth's Evidence IQ capability exists for. Detection tells you something anomalous happened. Evidence tells you which principal, acting under which delegation, requested which operation on which resource, and what the policy decided and on what inputs. The first is a signal. The second is a reconstructable chain. Only the second turns "suspected" into "confirmed" or "ruled out," and only the second survives a regulator, an auditor or an insurer asking the obvious question.

4. Security is losing the governance seat while agents gain the production floor

The share of companies where security drives AI governance fell from 33% to 21%. The share where security is not formally involved rose from 13% to 21%. 57% describe security as one voice among many, alongside legal, compliance and data. Lightspeed's own words: "Security is losing ground in AI governance."

The correlations are striking, with the causal caveat already stated. Among CISOs reporting no confirmed or suspected AI incident, 48% say security drives AI governance; among those reporting one, 13%. Among confident teams, 31% say security leads; among less confident teams, 9%. Confidence itself fell: 55% are fully or mostly confident their team can assess and mitigate AI-specific risk, down from 71%, and the share fully confident halved from 16% to 9%.

Two implications for anyone building or buying the control this paper describes.

First, the buyer is often not the CISO. At one in five companies security is not formally in the room, and at more than half it is one voice. The owner of AI risk may be the CIO, the chief data and AI officer, or a governance committee chaired by legal. Lightspeed partner Justin Shen's advice to founders applies equally to CISOs making the internal case: "one of the first questions should be who owns AI risk at the account." A runtime authorization layer is unusual among security controls in that it is also a governance control; it is the mechanism by which the AI governance committee's policies become enforced facts rather than documents. That is the argument that gets security back into the room.

Second, the median security team is now 35 people, and nearly two-thirds run teams under 50. Any control that requires a human to review each agent's permissions, approve each new tool integration, or investigate each suspected incident by hand will not scale with a shrinking team. This is the operational case for policy-as-code: authorization rules written once, versioned in Git, tested in CI, reviewed in pull requests and enforced at runtime, so that the security posture evolves at the speed of the engineering team rather than the ticket queue. Guru Chahal's framing is the right design target: "products that give a 35-person security team access to expertise it can't easily hire."

5. The human is already out of the loop. CISOs wrote the spec to expand it.

88% of companies already let AI execute security response actions (blocking traffic, isolating endpoints, revoking credentials) without prior human approval. 71% limit that to a narrow set of low-risk actions; 17% allow it broadly across response workflows. Only 12% require a human to approve every action, and 1% have ruled autonomy out. 30% already run an agentic SOC.

Lightspeed then asked 200 CISOs, in their own words, what would have to be true to let an agent take containment or response actions without approval. The rough tally: six in ten named proven accuracy, a track record or testing; three in ten named scoped permissions or predefined limits; a quarter named audit logs and monitoring; one in five named rollback or reversibility. One response captured all of it: "bounded low-impact blast radiuses, deterministic rollbacks, strict scope constraints, real-time logging, and exceptionally low false positive error rates."

Read that list as an engineer and it is a requirements document for a policy decision point. Scoped permissions and predefined limits are policy. Audit logs are decision logs. Rollback requires knowing precisely what was done, under what authority, which is the evidence chain from Section 3. Proven accuracy is a track record of decisions you can replay against the policy version that produced them. The 88% have built the first half of this, the ability to act, and are asking the market for the second half, the ability to bound and prove the action.

One design point the survey implies but does not state: binary allow/deny is not enough. If the only options are "the agent may do it" and "the agent may not," then every ambiguous action either gets over-permitted or gets routed to a human, and humans who are asked to approve hundreds of routine agent actions a day stop reading them. A runtime authorization layer needs a third verdict, escalate, assigned by risk tier in policy: routine actions resolve automatically, high-value or irreversible ones require a named human with a recorded decision, and the tier boundaries are themselves versioned policy. That is how autonomy expands, as the CISOs asked, on recorded performance.

6. What CISOs are budgeting for in 2027, and why two line items are one control

Every CISO surveyed plans to evaluate at least one AI security tool category in the next 12 months. The ranking: agent identity, authorization and access governance (55%); AI-powered risk scoring and behavior analytics (49%); runtime guardrails for AI agents in production (48%); model firewalls and API-layer security (46%); LLM red teaming (44%); secure inference platforms (43%); autonomous pen testing (40%). Last year's leaders, model access governance and secure inference, have given way to identity and runtime.

Budgets support it. 85% expect security budgets to rise, 82% commit more than 5% of the security budget to AI, and the share committing more than 10% rose from 27% to 31%. Non-human identity management, meanwhile, has the lowest current AI adoption of any stack category at 26%, despite 41% naming ungoverned agent credentials a top threat. The money is moving toward the gap.

The important reading is that the #1 and #3 categories describe the same control from two directions. "Identity, authorization and access governance" is the control described from the identity side: who is this agent and what is it entitled to. "Runtime guardrails for agents in production" is the control described from the action side: what is this agent about to do and should it be allowed. Buy them as separate products and you get an identity system that cannot see actions and a guardrail that cannot see entitlements, with the gap between them exactly where a hijacked agent operates. Runtime authorization is the point where the two meet: an identity-aware, action-level decision, made outside the model, per call.

7. Why the obvious alternatives stop short

The Cyber60 list itself includes strong companies in agent identity, agent visibility, credential brokering and developer identity. The survey's six opportunity areas will be contested by all of them, and by the identity and endpoint platforms that have announced AI security control planes. Each of these does something necessary. The structural reason none of them is sufficient is worth stating plainly, with respect for what they do well.

Identity governance and non-human identity platforms answer who the agent is, what it owns, when its credentials rotate and when it should be decommissioned. This is the inventory and identity half of the survey's top category, and it is essential: you cannot authorize a principal you cannot name. What identity governance does not do is evaluate the action. A scoped role is decided at provisioning; the transaction happens later, in a state the role could not anticipate. "This agent may access the payments API" is a grant. "This agent, acting for this user, may move this amount to this new payee at 2 a.m. on a Sunday" is a decision. Identity systems issue grants.

Model guardrails and AI safety controls (system prompts, refusal policies, content filters, alignment) shape what the model says and tends to do. They are the right tool for output quality and for reducing the probability of harmful behavior. They are probabilistic by construction, and they live inside the thing being attacked. A sufficiently clever injection, a sufficiently long context, a sufficiently capable model finding a sufficiently creative path, and the guardrail is advisory. Polite AI is not secure AI. Safety reduces the odds the agent attempts the wrong action; security is the deterministic check, outside the model, that the wrong action does not execute.

Vendor sandboxes and containment treat the model as the thing to be contained. Regulated enterprises have already learned this year that containment is provisional. The control that holds when containment fails is the one that sits in front of the resource rather than around the model.

Detection platforms, including the AI security control planes announced by endpoint and identity vendors, score risk and spot anomalies. They are excellent at the question "is this behavior unusual?" They cannot resolve "is this legitimate-looking behavior authorized?" A segregation-of-duties violation, a cross-tenant read, a transaction over a delegated limit, a sub-agent exceeding its parent's purpose: none of these is anomalous in the statistical sense. They are perfectly normal API calls that policy forbids. Risk scores are a valuable input to an authorization decision. They are not the decision.

Raw OPA deployed in-house is the honest alternative for teams that already run policy-as-code. Open Policy Agent is a superb engine and the one EnforceAuth is built on. An engine is not a car. Agent identity modeling, delegation-chain context, decision logs tied to signed policy versions, SIEM export, multi-region high availability, and the operational tooling to let a 35-person team run it are the difference between a policy engine and an authorization layer.

The positioning that follows is integration, not replacement. Identity systems issue the agent's identity; the authorization layer consumes it. Detection platforms produce risk signals; the authorization layer takes them as policy inputs. Credential brokers keep the secret away from the model; the authorization layer decides what the securely-authenticated agent may then do. The survey's near-even split between AI-native point solutions (53%) and consolidation (48%), with incident-experienced CISOs leaning to specialists at 60%, suggests both buyers exist. For the consolidator, runtime authorization is the control that makes the platform's AI story enforceable. For the specialist buyer, it is the point solution that closes the specific gap the survey describes.

7b. What the Cyber60 report misses

A report built from a CISO survey inherits the CISOs' blind spots. Three are worth naming, because each one makes the authorization gap wider than the survey shows.

Delegation chains and agent-to-agent protocols. The survey asks about agents as if each were a single principal. In practice an orchestrator spawns sub-agents, sub-agents call MCP servers, and MCP servers call other services, often across organizational boundaries via A2A-style protocols. Authority is transferred at each hop and, in nearly every deployment we have examined, widened rather than narrowed. The survey's 'hijacked agent' is usually a hijacked sub-agent three hops from any identity the IdP has heard of. Inventory (20%) undercounts this by construction, because the sub-agents exist for seconds. The only control that scales to ephemeral principals is one that evaluates the delegation chain itself as an input to every decision, which is why the Rego in Section 9 bounds a sub-agent by its parent's declared purpose, not merely its scope.

The non-security buyer. Lightspeed surveyed CISOs, and 21% of them are not formally in the AI governance room. The people who are, the CIO, the CDAO, legal and compliance, were not surveyed. Their requirements (traceability for the EU AI Act, model-risk evidence for regulators, contractual liability when an agent acts) are authorization requirements phrased in governance language. The report's market map is a security map; the budget map is broader.

Legitimate-but-unauthorized actions. Every threat the survey names is adversarial: hijack, injection, compromised credentials, supply chain. The largest class of agent harm in regulated industries is not adversarial at all. It is a correctly functioning agent doing a correctly requested thing that policy forbids: a cross-tenant read, a segregation-of-duties violation, a payment above a delegated limit, a disclosure to a model the data was never cleared for. No detection platform flags these because nothing is anomalous. Only policy knows they are wrong. The survey does not ask about them, and so understates the case.

The adversarial reading, and the answer to it

An identity vendor reads this paper and says: 'Fine-grained entitlements and just-in-time access already do this. Give the agent a tightly scoped identity, rotate it, and you have bounded the blast radius.' That is the strongest counter-argument and it deserves a direct answer. Scoped identity bounds the set of resources an agent can touch. It cannot bound the transactions it performs on them, because transaction legitimacy depends on state the identity system does not see: the amount, the counterparty, the time, the prior steps in the workflow, who delegated the task, and what the business rule says about that combination. 'May access the payments API' is a grant. 'May move this amount to this new payee at 2 a.m. on a Sunday on behalf of a user who is on leave' is a decision. Identity systems issue grants. If your identity vendor's product can take that sentence as input and return allow, deny or escalate per call with a replayable log, it is a runtime authorization layer and this paper applies to it. If it cannot, the gap stands.

A detection vendor reads this paper and says: 'Behavioral analytics catches the hijacked agent faster than any policy you could write.' Often true, and the right design uses that signal. But a risk score is probabilistic and a business rule is not. Segregation of duties is not a 0.7. The correct architecture consumes the detection vendor's score as one input to a deterministic decision, which is exactly how the reference architecture in Section 8 is drawn.

8. Reference architecture

The architecture has five components and one loop.

The identity provider (Okta, Entra, Ping, or an internal directory) issues a distinct identity to each agent, with the human principal it acts for and the delegation chain if it was spawned by another agent. This is the survey's 34%, made universal.

The agent or orchestrator plans and proposes actions. It is treated as untrusted input to the authorization layer, in the same way a browser is untrusted input to a web application. Nothing about the model's reasoning is relied on for enforcement.

The policy enforcement point sits at the tool or MCP gateway, the API gateway, the service mesh, or inside the application, and intercepts every tool call before it reaches a resource. EnforceAuth ships this as Herald, an authorization MCP server, and integrates with existing gateways and meshes rather than requiring a new one.

The policy decision point, EnforceAuth's PDP fleet, evaluates each request against versioned Rego policy with Evidence IQ supplying the context the request itself does not carry: the delegation chain, the relationships between principals and resources, the current application state, prior decisions in the same workflow, and risk signals from detection platforms. It returns allow, deny or escalate, and writes a decision log entry tied to the exact policy version that produced it.

The protected resource (CRM, ERP, database, payment rail, internal API) executes only on allow. It never sees the model.

The loop: decision logs stream to the SIEM (Splunk, Datadog, S3), policy lives as signed bundles in Git, and any decision can be replayed against the policy version that produced it. That loop is the evidence chain from Section 3, the audit trail from Section 5, and the track record on which autonomy expands.

Deployment modes shipping today: multi-tenant SaaS (NA, EU, APAC regions), single-tenant SaaS, bring-your-own-cloud via Terraform or Pulumi, and air-gapped on-premises. SSO (SAML/OIDC), SCIM provisioning and the OpenID AuthZEN API are supported. Performance design targets for the PDP are sub-2ms median and sub-5ms p99 decision latency at 100K+ decisions per second per node; these are design targets, not published benchmarks, and should be validated in your environment. Cedar and Zanzibar-style relationship policies are on the roadmap. SOC 2 Type II is in progress.

9. A worked example: the policy the survey is asking for

The following Rego expresses three of the survey's findings as enforceable policy. It is deliberately simple; production policy is larger, tested in CI and reviewed in pull requests like any other code.

package agent.authz default decision := {"verdict": "deny", "reason": "no matching rule"} # Finding: 26% pass human credentials to agents. # Rule: an agent acting for a human may never exceed that human's # effective scope, and must be a distinct principal in the log. human_scope_ok if { input.principal.type == "agent" input.principal.acts_for != null input.action in data.scopes[input.principal.acts_for] } # Finding: "one compromised agent shouldn't be able to influence the others." # Rule: a sub-agent's authority is bounded by its parent's declared purpose, # not just the parent's scope. delegation_ok if { count(input.principal.delegation_chain) == 0 } delegation_ok if { parent := input.principal.delegation_chain[count(input.principal.delegation_chain) - 1] input.action in data.purpose_actions[parent.purpose] } # Finding: CISOs will expand autonomy on scope + audit + rollback. # Rule: routine actions resolve automatically; irreversible or # high-value actions escalate to a named human with a recorded decision. risk_tier := data.action_risk[input.action] decision := {"verdict": "allow", "reason": "in scope, in purpose, routine"} if { human_scope_ok delegation_ok risk_tier == "routine" } decision := {"verdict": "escalate", "approver": data.approvers[input.resource.owner], "reason": "in scope but irreversible or over limit"} if { human_scope_ok delegation_ok risk_tier == "high" }

Three properties to notice. The model is not consulted; the decision depends on principal, delegation chain, action, resource and data, all of which are facts outside the agent's reasoning. The decision log entry records which rule fired and on which inputs, so a "suspected" incident becomes a query. And the risk tiers are data, versioned alongside the policy, so expanding autonomy is a reviewed pull request rather than a configuration change nobody can later explain.

10. Mapping the six Lightspeed opportunity areas

Lightspeed closes the report with six areas where CISO pain signals market need. Mapped against the architecture above:

1. Agent identity and access governance. Directly addressed: per-agent identity consumed from the IdP, scoped and just-in-time authorization enforced at the tool and API layer, detection of permission creep as a policy rule rather than an alert, and attribution that separates agent from human in the log. Lightspeed's own market-opportunity list under this heading reads as a feature list for this layer.
2. Agent runtime security. Directly addressed for the enforcement half: runtime constraints on what an agent can do regardless of what it is told, authority bounds on agent-to-agent interaction, and supply-chain containment by treating every MCP server and connector as a principal with its own policy. Discovery and inventory of agents deployed outside security's view is adjacent, and the right partners for it are on the Cyber60 list.
3. Trusted autonomous response. Directly addressed: the policy engine that defines which actions an agent may take alone and which escalate is the exact item on Lightspeed's list, and the decision log is the evidence trail and track record the CISOs named as preconditions.
4. Application security for AI-generated code. Partially addressed. Static analysis of generated code is not an authorization problem. Policy enforcement for what AI-generated code may reach at runtime is, and it is the backstop when the review capacity the survey says is overwhelmed (87% report more AppSec work) misses something.
5. AI data leakage and shadow AI. Addressed for sanctioned agents: policy on what data may reach which model, and on what agents may read, retain and send to outside systems, is an authorization decision at the tool call. Discovery of unsanctioned employee AI use is a visibility problem for other tools.
6. Defense against AI-generated deception. Not an authorization problem. Deepfake and synthetic-identity detection belongs to specialists, with one exception: the high-value workflows Lightspeed names (payments, access requests, executive communications) are exactly where an escalate verdict with out-of-band human approval limits the damage a successful deception can do.

Four of six, with the other two bounded. That is the claim the executive summary made, and this is the demonstration.

11. Regulatory context, briefly

The survey does not ask about regulation, so this section is short and the paper does not offer legal advice. Three facts are relevant to anyone building the business case. DORA has been in force for EU financial entities since January 2025 and requires demonstrable control over ICT-related risk including third-party and automated systems; a per-action decision log is a direct answer to its evidence requirements. The EU AI Act's obligations for high-risk systems phase in from August 2026 and emphasize human oversight, logging and traceability, which map to the escalate verdict and the decision log. The NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications both name excessive agency, tool misuse and insufficient authorization as core risks. None of this requires a specific product. All of it requires a per-action, attributable, replayable authorization record, which most of the surveyed companies do not yet produce.

12. Business value: a four-driver model

No pricing is quoted here; the value model is meant to be filled in with your own numbers. Four drivers, in order of how quickly they can be measured.

Incident cost avoided. The survey's 51% fear of hijacked agents is a fear about blast radius. Bounding every agent action to policy converts a potential full-permission incident into a denied request with a log entry. Use your own incident cost assumptions; published industry averages for breach cost run into the millions and rise with time to identify and contain, which is precisely the interval an evidence chain shortens.

Investigation and audit hours recovered. 63% of CISOs suspected an AI incident they could not confirm. Each unconfirmed suspicion is investigator time. A replayable decision log turns a multi-day reconstruction into a query. Audit preparation for DORA, SOX, HIPAA or the AI Act follows the same arithmetic.

Autonomy unlocked. 71% of companies cap AI response at low-risk actions because they lack scope, audit and rollback. Every action that can safely move from "human approves" to "policy allows" or "policy escalates only on exception" is analyst time returned, and it is the survey's own stated path to expanding autonomy.

Engineering velocity preserved. Policy-as-code means the security team reviews pull requests instead of blocking releases. For companies where 87% report more AppSec work from AI-generated code, authorization that ships with the code rather than after it is the only control model that does not slow the business.

13. Implementation: 30, 60, 90 days

Days 1–30: inventory and identity. Enumerate every agent, including the ones outside security's view, and give each a distinct identity in the IdP with the human it acts for. Retire shared service accounts for agents. This alone moves a company from the 80% without a complete inventory into the 20%, and from the 26% on human credentials to the 34%. EnforceAuth's open-source zift tool scans codebases for existing authorization logic to accelerate this step.

Days 31–60: enforce at the choke point. Deploy the policy enforcement point at the tool or MCP gateway for the highest-value workflows first (payments, customer data, production infrastructure). Start with policy in audit-only mode, logging what would have been denied. Review the log with the business owners. This is where the organization discovers what its agents actually do.

Days 61–90: enforce, escalate, expand. Switch the highest-risk actions to enforce. Assign risk tiers in policy data and turn on escalate for irreversible or over-limit actions. Stream decision logs to the SIEM. Begin the recorded track record on which autonomy is expanded, one reviewed pull request at a time.

Team requirements are modest by design: one engineer who can write Rego (or learn it in a week), one security owner for policy review, and the existing platform team for gateway integration.

13b. What good looks like in twelve months: a scorecard

Lightspeed's survey is a baseline. These are the targets a board can hold the program to, each phrased so it can be measured from the decision log rather than a slide.

• Inventory completeness: 100% of agents that touched a protected resource in the last 30 days have a distinct identity in the IdP and appear in the decision log. (Survey baseline: 20% complete inventory.)
• Credential hygiene: 0 agent actions executed under a human user's credentials or a shared service account. (Baseline: 41% of companies do one or both.)
• Coverage: 100% of tool calls into payments, customer data and production infrastructure pass through a policy enforcement point. Measured as PEP-logged calls divided by gateway-observed calls.
• Evidence: any agent action in the last 90 days reconstructable to principal, delegation chain, action, resource, policy version and decision in under 5 minutes by query, not investigation. (Baseline: 63% suspected-but-unconfirmed incidents.)
• Autonomy: share of response actions resolved by policy without a human, with an escalation rate under 5% and a post-hoc override rate under 1%. Autonomy expands only when both hold for a quarter. (Baseline: 71% capped at low-risk actions.)
• Governance: the security team owns the policy repository and every change to agent permissions is a reviewed pull request. (Baseline: security drives AI governance at 21%.)

14. Ten questions, mapped to the survey

Answer these for your own environment. Each maps to a finding in the report.

1. Can you produce a complete list of every AI agent operating in your environment today, including those outside security's view? (20% can.)
2. Does every agent have its own identity, distinct in the audit log from the human it acts for? (34% intend to.)
3. When an agent is spawned by another agent, is the sub-agent's authority bounded by the parent's purpose, or only by the parent's scope? (The survey's own CISOs asked for this.)
4. For any agent action in the last 30 days, can you show which policy allowed it and on what inputs? (The 63% could not.)
5. If an agent is prompt-injected, what is the largest action it can complete without a policy check? (51% fear the answer.)
6. Which agent actions execute with no human approval, and where is that list versioned? (88% have such a list; few have it in Git.)
7. Is there a third verdict between allow and deny, and who receives the escalation? (Binary policy produces approval fatigue.)
8. Can you replay any decision against the policy version that produced it? (Rollback and track record require it.)
9. Who owns AI risk in your organization, and does security have authority over agent permissions? (Security leads at 21%.)
10. If your model vendor's containment failed tomorrow, which control would still hold at the resource? (Containment is provisional.)

If the answer to four or more is "no" or "not sure," the survey has already described your gap. It is an authorization gap, and it is closable.

Conclusion

Lightspeed and Fortune asked 200 CISOs about AI agents and got back a remarkably coherent answer: the agents are deployed, the inventory is partial, the identities are borrowed, the top threat is the agent itself, the human is already out of the loop, and the money for 2027 is going to agent identity, authorization and runtime control. The report is careful to say the survey shows where CISOs are struggling, not why, and this paper has tried to honor that care.

But the direction is not ambiguous. The industry has spent two years making AI polite. The next year, by the CISOs' own account, is about making it authorized. Polite AI is not secure AI. The difference is a deterministic decision, made outside the model, for every action, with evidence. That is the layer the agent enterprise is missing, and it is the one EnforceAuth was built to be.

Next step. EnforceAuth offers a two-week Agent Authorization Assessment: we inventory your agents, map their current credentials and tool access against the ten questions above, and return a prioritized policy plan in Rego you own regardless of what you buy. Request it at enforceauth.com.

Source. Lightspeed Venture Partners and Fortune, "Cyber60 2026-2027 — CISO Survey: Securing the Agent Enterprise," published October 28, 2026. Survey by Wakefield Research among 200 U.S. CISOs at companies with $500M+ revenue, September 4–14, 2026; margin of error ±6.9 points at 95% confidence; 2025 comparisons from the July 29–August 6, 2025 survey. https://lsvp.com/cyber60-2026-2027/