AEPVL: AI Security Production Readiness

AI security is often discussed at the level of policy, model behaviour, prompt controls, or post-deployment monitoring.

Those controls matter, but they do not secure the complete production system.

A production AI workflow may accept a user request, retrieve internal data, assemble context, call one or more tools, recommend an action, trigger a downstream process, retain memory, request approval, and alter a business system.

The model is only one component in that path.

The security boundary extends from the identity initiating the workflow to the business consequence created at the end of it.

That creates a practical architecture problem.

Who is allowed to ask?

What data may be retrieved?

Which tools may be invoked?

Where are restrictions technically applied?

What evidence must be retained?

Which decisions should remain deterministic?

Which actions require human approval?

Can the organisation later explain what happened and why?

AEPVL is Krisova’s method for examining those questions before an AI or agentic AI system reaches production.

The frozen sequence is:

Authorize → Enforce → Preserve → Validate → Log

Each pillar addresses a different part of the decision and action lifecycle. Together, they provide an architecture-led way to identify control gaps, define implementation responsibilities, and establish production evidence.

AEPVL is not intended to replace security engineering, secure software development, platform security, privacy controls, or enterprise architecture.

It helps those disciplines converge around the specific risks created when AI systems access context, make decisions, use tools, and influence downstream actions.

Why model-level controls are insufficient

A model can be instructed not to disclose sensitive information.

That instruction does not determine whether the retrieval layer is permitted to access the information in the first place.

A model can be instructed not to execute a high-value transaction.

That instruction does not remove its access to the transaction tool.

A policy can state that human approval is required.

That policy is ineffective if the runtime path allows the agent to bypass the approval step.

Monitoring may later show that an unsafe action occurred.

Monitoring does not prevent the action, validate it before execution, or prove which authority and policy were applied.

Production AI therefore needs controls across the complete decision path:

Identity
→ Request
→ Context and Retrieval
→ Model Decision
→ Tool or Action Request
→ Validation and Approval
→ Downstream Effect
→ Evidence and Reporting

Security becomes incomplete when any material part of this path depends only on model discretion, undocumented process, or retrospective review.

The five production questions

AEPVL reduces the AI decision and action lifecycle to five production questions:

Authorize: Was the actor, request, data access, tool use, and intended action permitted?
Enforce: Were the restrictions applied at the point where misuse could actually be prevented?
Preserve: Was enough context and evidence retained to examine the decision without unnecessarily retaining sensitive data?
Validate: Were the output, action, approval, and downstream effect checked independently?
Log: Can the organisation reconstruct what happened, why it happened, and what controls were applied?

These questions are deliberately architectural.

They require explicit boundaries, owners, interfaces, evidence, and failure behaviour.

1. Authorize

Purpose

Authorize establishes who or what may initiate an AI workflow, retrieve data, invoke tools, or request a downstream action.

Authentication alone is not sufficient.

A valid user may still lack authority for a specific record, purpose, tool, or action.

An AI agent may act on behalf of a user, service, department, or workflow. Its authority must therefore be derived, scoped, and limited.

Core questions

Is the initiating user, workload, service, or agent identity known?
Is the request permitted for the actor’s role and purpose?
Does the actor have authority to retrieve the requested data?
Is consent present, current, and applicable?
Which tools may this workflow use?
Which actions may the agent request?
Can authority be delegated, and under what limits?
Does the authority remain valid throughout a long-running workflow?

Representative threat vectors

identity spoofing;
privilege escalation;
unauthorised retrieval;
excessive agent delegation;
reuse of expired consent;
cross-tenant access;
confused-deputy behaviour;
tool invocation outside the user’s authority.

Architecture controls

user and workload identity;
role, entitlement, consent, and purpose checks;
scoped access tokens;
delegated-authority limits;
explicit tool permissions;
tenant and data-boundary enforcement;
action-specific authorisation;
re-authorisation for consequential actions.

Evidence to retain

actor or workload reference;
requested scope;
purpose and consent reference;
policy version;
authorisation result;
allowed or denied resources and actions;
reason or decision reference.

Failure example

An authenticated user asks an AI assistant to summarise records outside their permitted scope. The application trusts the authenticated session, and the retrieval service does not independently evaluate data authority.

Production-readiness checks

Authority is evaluated for the requested data and action, not only at login.
Agent authority is narrower than the combined authority of every connected tool.
Consent and entitlement changes take effect predictably.
Denied actions cannot be recovered through alternate prompts or tool paths.

2. Enforce

Purpose

Enforce determines where policy, data, tool, runtime, output, and action restrictions are technically applied.

A control that exists only in a prompt or policy document is advisory.

Production control requires an enforcement point outside discretionary model reasoning.

Core questions

Where is the policy decision made?
Where is it enforced?
Can the model or agent bypass the enforcement point?
Are retrieval limits applied before data is returned?
Are tool parameters and actions constrained?
Are transaction, cost, time, and iteration limits enforced?
What happens if a policy or identity service is unavailable?
Does the system fail closed for consequential actions?

Representative threat vectors

prompt injection;
policy bypass;
tool misuse;
excessive retrieval;
unrestricted action execution;
unsafe parameter generation;
runaway loops;
fail-open behaviour;
indirect prompt manipulation through retrieved content.

Architecture controls

policy decision and enforcement points;
API and tool gateways;
allowlisted tools and operations;
schema and parameter validation;
retrieval filters;
transaction and cost limits;
runtime isolation;
rate and iteration limits;
deterministic deny paths;
policy re-evaluation before action execution.

Evidence to retain

policy decision;
enforcement point;
operation requested;
operation allowed, transformed, or rejected;
applied limits;
failure behaviour;
exception or override reference.

Failure example

A system prompt states that the agent cannot approve financial transactions. The agent still has direct access to the approval API, and manipulated retrieved content causes it to invoke that API.

Production-readiness checks

Material restrictions exist outside prompts.
Retrieval, tools, and actions are mediated by explicit enforcement points.
Failure behaviour is defined and tested.
The model cannot silently expand its own permissions.
Control exceptions are explicit, time-bounded, and reviewable.

3. Preserve

Purpose

Preserve defines what context, consent, versions, approvals, and evidence must remain available for review.

The objective is not to store everything.

Uncontrolled retention can create privacy, security, and legal risk.

The objective is to preserve sufficient evidence to understand the decision while minimising unnecessary sensitive content.

Core questions

Which inputs and context affected the decision?
Which model, prompt, retrieval, tool, and policy versions were used?
Was consent valid at the time?
Which approvals or overrides were present?
Can references, hashes, or structured claims be retained instead of raw content?
Is the evidence protected from alteration?
Are retention periods defined?
Can memory or long-term context be distinguished from transient context?

Representative threat vectors

missing provenance;
altered evidence;
excessive sensitive-data retention;
model or prompt version ambiguity;
unreviewable consent;
unverifiable retrieval context;
uncontrolled agent memory;
inability to reproduce the decision state.

Architecture controls

versioned context references;
retrieval provenance;
prompt and model versioning;
consent and approval references;
evidence minimisation;
content hashes;
tamper-evident storage;
access-controlled evidence repositories;
memory retention and deletion policies;
separation of business data from audit evidence.

Evidence to retain

model, prompt, tool, and policy versions;
retrieval references;
consent state;
context and memory references;
approval and override references;
integrity metadata;
retention classification.

Failure example

A disputed decision cannot be investigated because the organisation retained only the final response. The retrieved documents, consent state, prompt version, policy decision, and approval context are unavailable.

Production-readiness checks

Required evidence is defined before deployment.
Sensitive content is not retained simply because it was available.
Evidence integrity is protected.
Memory and context have explicit retention boundaries.
Reviewers can determine which versions and inputs affected the decision.

4. Validate

Purpose

Validate independently checks outputs, policy decisions, action requests, approvals, and downstream effects.

A model should not be the sole authority for accepting its own consequential output.

Validation may occur before execution, after execution, or at both points.

Core questions

Which outputs require deterministic checks?
Which actions require human approval?
Are generated fields checked against schemas and business rules?
Are policy outcomes independently re-evaluated?
Can the same model generate and approve an action?
Are tool responses trusted without verification?
Is the downstream effect confirmed?
What happens when validation is inconclusive?

Representative threat vectors

hallucinated facts;
unsafe action parameters;
invalid policy interpretation;
self-approval;
unverified tool responses;
incomplete execution;
harmful downstream effects;
invalid or inconsistent business decisions.

Architecture controls

schema validation;
deterministic business rules;
policy re-evaluation;
secondary verification;
human approval gates;
transaction reconciliation;
downstream confirmation;
confidence-independent safety checks;
rejection and quarantine paths;
separation of proposal from execution.

Evidence to retain

validation result;
rule or reviewer reference;
rejected fields or reasons;
approval record;
downstream confirmation;
exception handling;
remediation or rollback outcome.

Failure example

An agent generates a refund request using a fabricated transaction reference and then accepts its own output because no independent business-rule or transaction validation exists.

Production-readiness checks

Consequential outputs are independently checked.
Irreversible or high-impact actions have appropriate approval.
Generated parameters are validated before tool execution.
Downstream systems confirm the actual result.
Failed or inconclusive validation produces a defined safe outcome.

5. Log

Purpose

Log creates the decision trail required to explain what happened, why it happened, what was allowed or denied, and what evidence supports the outcome.

A useful log is not an uncontrolled dump of prompts, model responses, and system events.

It is a structured record of the decisions and controls that mattered.

Core questions

What was requested?
Who or what initiated the request?
What authority and policy were applied?
Which data, tools, and actions were allowed or denied?
Which validation and approval steps occurred?
What downstream effect resulted?
Can events be correlated across systems?
Can a reviewer distinguish attempted, approved, executed, rejected, and failed actions?

Representative threat vectors

incomplete audit trail;
untraceable override;
missing event correlation;
excessive sensitive logging;
inconsistent records across systems;
inability to explain downstream effects;
attempted actions omitted from audit history.

Architecture controls

structured decision events;
correlation identifiers;
actor and workflow references;
policy and evidence references;
tamper-evident records;
override logging;
access-controlled audit views;
event status and outcome tracking;
sensitive-data minimisation.

Evidence to retain

actor and workflow reference;
request and intended action;
authorisation and enforcement results;
validation and approval outcomes;
evidence references;
timestamps and correlation identifiers;
final downstream status;
override and exception details.

Failure example

A downstream record was changed, but the organisation cannot determine which user request, retrieved data, model output, tool call, policy decision, or approval led to the change.

Production-readiness checks

The decision chain can be reconstructed end to end.
Denied, failed, and overridden actions are recorded.
Logs preserve proof without unnecessarily storing sensitive content.
Events across retrieval, model, tools, approvals, and downstream systems can be correlated.
Reporting can distinguish control effectiveness from system activity.

What must remain deterministic

Some responsibilities should not be delegated to probabilistic model reasoning.

These typically include:

identity verification;
entitlement and consent evaluation;
policy enforcement;
tool and transaction limits;
schema validation;
required approval gates;
audit-event creation;
evidence integrity;
deny and failure behaviour;
execution of irreversible actions without explicit control.

AI may assist with interpretation, classification, recommendation, and prioritisation.

It should not silently redefine the controls governing its own authority.

Where human review belongs

Human review should be designed around consequence, uncertainty, and reversibility.

It may be required when:

an action is irreversible;
financial, legal, safety, or customer impact is material;
the requested action exceeds an established threshold;
model output conflicts with deterministic rules;
data quality is insufficient;
consent or authority is ambiguous;
a policy exception is requested;
the downstream effect cannot be automatically verified.

Human review must not exist only as a documented expectation.

It must be placed as an explicit control in the execution path, with defined authority and retained evidence.

End-to-end agentic AI scenario

Consider an AI agent that prepares and initiates a customer account change.

The agent receives a user request, retrieves account information, evaluates the requested change, calls an internal tool, and updates a downstream system.

Authorize

The system verifies the user, account relationship, purpose, consent, and the agent’s delegated authority.

The agent is permitted to retrieve only the required records and request only a defined set of account changes.

Enforce

Retrieval restrictions are applied before data is returned.

The tool gateway limits the available operation, accepted fields, transaction values, and execution frequency.

The agent cannot bypass the approval requirement through prompt variation.

Preserve

The system retains references to the user identity, consent state, model and policy versions, retrieved records, tool version, and approval.

Raw sensitive context is retained only where necessary.

Validate

The proposed change is checked against deterministic business and security rules.

A human approval is required where the change exceeds an established threshold.

The downstream system confirms the actual state after execution.

Log

The decision trail links the request, authority, retrieved context, policy result, proposed action, approval, tool invocation, and downstream outcome.

A reviewer can later determine what was requested, what was allowed, what was executed, and why.

Compact threat-vector matrix

Threat vector	Primary pillar	Supporting pillar
Unauthorised data retrieval	Authorize	Enforce
Prompt-induced tool misuse	Enforce	Validate
Expired or missing consent	Authorize	Preserve
Excessive agent delegation	Authorize	Enforce
Unsafe generated action	Validate	Enforce
Missing provenance	Preserve	Log
Excessive sensitive retention	Preserve	Authorize
Untraceable human override	Log	Validate
Downstream action mismatch	Validate	Log
Policy failure causing fail-open behaviour	Enforce	Log

Threats frequently cross more than one pillar. This matrix is representative rather than exhaustive.

Production-readiness checklist

Before production, leaders should be able to answer yes to the following:

Are users, services, workloads, and agents tied to identifiable authority?
Is data access evaluated independently of model instructions?
Are tool and action permissions explicitly constrained?
Do material controls fail safely when identity or policy services are unavailable?
Are model, prompt, policy, tool, context, and consent versions identifiable?
Is evidence retention defined and minimised?
Are consequential outputs checked using deterministic rules?
Are high-impact or irreversible actions subject to appropriate human approval?
Are downstream results confirmed independently?
Can the complete decision trail be reconstructed?

A negative answer does not automatically mean the system cannot proceed.

It does indicate a control gap that must be resolved, reduced, or explicitly accepted before production.

CISO reporting view

AEPVL can support a compact CISO view focused on implemented controls and evidence.

Useful measures include:

percentage of AI workflows with explicit authority checks;
percentage with independent policy-enforcement points;
percentage with defined evidence retention;
percentage of consequential actions independently validated;
percentage with reconstructable decision trails;
number of high-severity control gaps;
number of human overrides and policy exceptions;
blocked or failed tool invocations;
unverified downstream actions;
ageing of unresolved production-readiness findings.

The purpose is not to create another reporting layer detached from implementation.

The reporting view should be derived from architecture controls and production evidence.

How AEPVL informs architecture and implementation

AEPVL is applied before and during implementation.

During architecture design, it helps identify:

trust and authority boundaries;
policy decision and enforcement points;
retrieval and data-access controls;
tool and agent permissions;
evidence and retention requirements;
validation and approval paths;
decision-event and reporting requirements.

During implementation planning, it helps translate those requirements into:

service responsibilities;
interfaces;
control points;
failure behaviour;
test scenarios;
production evidence;
operational ownership.

AEPVL does not replace security engineering.

Security engineering implements and operates the controls.

AEPVL helps determine where those controls must exist across the AI decision and action lifecycle, what evidence should be available, and how the controls should converge before production.

What AEPVL is not

AEPVL is:

not a general enterprise-governance framework;
not a responsible-AI principles statement;
not a policy-only model;
not a compliance certification;
not an industry standard;
not a model benchmark;
not a replacement for application, cloud, data, identity, or platform security;
not a claim that every AI risk can be eliminated;
not yet presented as proven at scale.

Its scope is narrower and practical: AI and agentic AI security production readiness.

Maturity and limitations

AEPVL is currently used by Krisova in architecture design and implementation planning.

All five pillars can be implemented using established architecture, security, identity, policy, data, evidence, validation, and observability controls.

The method is informed by active production-readiness work. Future releases will incorporate additional implementation evidence, operating metrics, and refined control mappings.

AEPVL should therefore be treated as an evolving Krisova method rather than a mature industry framework or certification scheme.

An anonymised implementation framing

In an active AI architecture context, the initial design focused heavily on model access, prompts, and monitoring.

The wider decision path revealed additional questions around user authority, retrieval scope, tool permissions, consent state, downstream actions, evidence retention, and audit reconstruction.

Applying the AEPVL sequence helped separate policy intent from technical enforcement, identify deterministic control points, define approval and validation responsibilities, and specify the evidence required before production.

The implementation remains context-specific. The value of the method is in making these control questions visible early enough to influence architecture and delivery.

Executive implication

AI security cannot be reduced to whether the model produces an acceptable response.

The production question is whether the full system can demonstrate:

who was authorised;
what was enforced;
what evidence was preserved;
what was independently validated;
what can be reconstructed later.

That is the role of AEPVL.