Should this access still be allowed?
Given who this is, who it acts for, what it has already done, how it is connected, and what has changed since we last checked.
- 97%
- of organizations breached through AI lacked proper AI access controls.
- $10.22M
- average cost of a U.S. data breach, a record high.
- 63%
- of breached organizations have no AI governance policy or are still writing one.
Source: IBM Cost of a Data Breach Report 2025 (Ponemon Institute)
01
The problem
Three blind spots.
Request-time authorization judges each request from zero. That model:
It forgets.
Each request is judged on its own. History may be logged, but the decision never uses it.
It sees attributes, not relationships.
It knows a user is in Finance, not that they delegated to an agent that spun up a second agent using a shared credential to reach a restricted database.
It stops watching after ALLOW.
Access stays granted until a token expires or the next request, even if identity, resource or risk changed seconds later.
ASI01
Agent Goal Hijack
Off-purpose sequences can be stepped up or revoked.
ASI02
Tool Misuse & Exploitation
Policy-as-code on tool calls, for the request and for the rest of the session.
ASI03
Identity & Privilege Abuse
When privileges or credentials change, access that depended on them is withdrawn, including access held through a chain of delegation.
ASI06
Memory & Context Poisoning
Poisoned or stale context does not quietly expand what an agent is allowed to do.
ASI07
Insecure Inter-Agent Communication
Agent-to-agent handoffs stay inside a chain of authority you can account for.
ASI08
Cascading Failures
When an upstream authority is revoked, the agents that depended on it lose that access.
ASI10
Rogue Agents
Agents that drift from their purpose can be quarantined at runtime.
Authorization can’t address every OWASP risk (e.g., code execution sandboxing), but it is the control point for many.
Request-time authorization, and continuous authorization.
Request-time authorization
“Is this request allowed right now?”
Continuous authorization
“Should this access still be allowed?”
Loop runs for the life of the session
02
The decision
What authorization does.
EnforceAuth authorizes humans and AI agents at runtime, and keeps checking.
Writ (control) → OPA/EAOPA engines (decide) → Writ → Evidence IQ (record)
Engines send decisions to Writ, and Writ feeds Evidence IQ. Recording is never in the decision path.
Act through the session.
Allow, deny, step up, revoke, or quarantine through the life of the session.
Explain the decision.
Policy-as-code, with the risk, behavior, and delegation behind it. Decisions show the rule that applied.
Remember the connections.
How identities, agents, and resources are connected, and how that changes.
Connect what you already run.
IdP, IGA, HRIS, PAM, CMDB, EDR, SIEM, cloud, SaaS, data, APIs, AI agents. Nothing ripped out.
If policy is missing or stale, restricted access fails closed. Recording problems never block a decision.
03
Capabilities
Seven capabilities that change the decision.
01
Authorization memory
What has this identity already done, and does this request still make sense?
A request is judged against what this identity has already done, not only the latest call.
02
Connection to the resource
How is this identity connected to this resource, and is that path acceptable?
Access depends on whether that connection is one you are willing to allow.
03
Continuous authorization
Has something happened that makes an earlier ALLOW no longer valid?
Re-evaluate promptly when identity, resource, risk, behavior, delegation or policy changes.
04
Delegation-chain authorization
Is there still a valid path of authority from the originating human to this action?
Authority can narrow as it travels. It can never grow.
05
Point-in-time decision reconstruction
Why exactly did we allow this at 2:37:14 PM on March 17?
Recorded decisions can be reconstructed and explained.
06
Purpose and history
Is this activity consistent with this identity’s purpose and history?
A jump from 50 CRM records a day to 250,000, plus an unfamiliar API, changes whether that access should continue.
07
Policy simulation and replay
What would this new policy have done over the last 30 days?
Replay against real history before promotion.
04
Enforcement
How enforcement works.
Where
- Agent and tool gateways, including MCP
- API gateways and service mesh
- Application SDKs
- Data access layers
- The identity and session layer
Revoking mid-session
An earlier allow can be withdrawn during the session when the context it depended on changes.
Step-up for an agent
An agent can’t answer MFA, so the action is paused and routed to a human approver with full context. Approval is a narrow, time-boxed exception, through Verdict.
An honest boundary
Continuous authorization governs the next action. It cannot undo an action that has already completed. It works best when each action is checked as it happens, and credentials do not outlive the session.
05
Trust
Trust in the system itself.
Policy stays in charge.
Open policy-as-code. Decisions explain the rule that applied and the context it used. Behavioral signals advise before they decide: observe, recommend, then enforce.
Resists manipulation.
An agent’s own claims about itself are never authoritative. Signals that are less trusted can raise scrutiny, and they never grant access on their own.
Protects the data.
Data minimization, tenant isolation, and access to context governed by EnforceAuth’s own policy. Security program details available under NDA.
06
Adoption
Earn the right to enforce.
01
Observe
One high-value agent workflow, shadow mode, nothing blocked.
02
Recommend
Replay candidate policies against real history. Humans approve.
03
Enforce
Turn on enforcement for the highest-risk paths first.
04
Expand
More agents, applications, and data domains.
Questions to ask of any authorization approach
- 1For any agent action, which human’s authority does it ultimately rest on?
- 2If a person is offboarded right now, how long until every agent acting for them loses access?
- 3Does it make decisions after ALLOW, or only at request time?
- 4Can it reconstruct the full context of a decision from six months ago?
- 5Can I test a policy change against real history before I enforce it?
- 6What happens when its context sources are down or stale?
- 7How does it keep an agent’s own claims about itself from influencing its access?
Evidence IQ
Decisions, on the record.
EnforceAuth decides. Evidence IQ keeps a durable, searchable record of what was decided and why. It is never in the decision path, so recording never slows or blocks access.
Recorded decisions can be reconstructed and explained to auditors and boards.
Engines send decisions to Writ, and Writ feeds Evidence IQ, the evidence record. Neither sits in the decision path.
Common questions