AI Compliance · Security & Controls

Engineering Secure AI Automation

A framework-led delivery model for building RAG systems, AI agents and enterprise automations that operate on real business data — with governance, access controls, tested failure handling and verifiable evidence designed in from the first architecture decision.

Written by Vladimir Zhemerov

Senior Product Manager & AIO/GEO SpecialistPublished 2026-06-20

A control model for systems that can retrieve and act

An AI system becomes part of an organisation's operating environment the moment it can read documents, query a CRM, route a request, prepare a report, update a record or initiate a downstream action. At that point performance depends on more than model quality. The system needs defined ownership, controlled data flows, constrained permissions, reliable evidence and a response plan for failure.

Internal knowledge assistants, customer-facing support, RAG applications, workflow automations, sales copilots and multi-step agents each combine a model with data sources, user identities, integrations and business processes — and each introduces trust boundaries that need engineering attention. An AI workflow has five operational layers.

01
Input
User requests, documents, messages, web pages, forms and API payloads.
02
Decision
Prompts, orchestration logic, model calls, routing and policy evaluation.
03
Knowledge
Source documents, databases, vector stores, metadata and retrieval filters.
04
Action
CRM updates, emails, tickets, payments, workflow triggers and API requests.
05
Oversight
Authentication, logs, evaluation, approval, monitoring and incident response.

Risk accumulates at the boundaries between those layers. A document uploaded into a knowledge base can carry an indirect prompt injection. A service account can grant an agent broader CRM access than the business process requires. A retrieved passage can be correct yet unavailable to the current user. A model output can become an instruction to an automation platform. The control model therefore covers the full system — the model, the orchestration layer, identities, source data, connectors and human approvals.

Figure 01 — AI automation trust boundaries

Where identity, filtering, scope and approval are enforced

Untrusted input → controlled action

User / external content

Prompts, files, web pages, emails

identity

AI orchestrator

Prompts, routing, model calls

ACL filter

RAG / knowledge base

Documents, vectors, metadata

scoped token

CRM / email / API tools

Actions on operational systems

approval gate

Human approval

Gate for high-impact actions

action schema

Logs & monitoring

Attributable, replayable evidence

audit event

Every boundary carries a control. The model never holds standing access — identity, entitlement, scope and approval are enforced around it.

The frameworks behind the delivery model

The model draws on several complementary sources, each with a specific role. Together they provide a common language for decisions, risk treatment and evidence. Their implementation reflects the organisation's sector, deployment model, risk appetite, contractual commitments and applicable law.

NIST AI Risk Management FrameworkStructures AI risk around Govern, Map, Measure and Manage across the lifecycle.
NIST Cybersecurity Framework 2.0Frames security outcomes through Govern, Identify, Protect, Detect, Respond and Recover.
ISO/IEC 42001:2023Requirements for an Artificial Intelligence Management System — policies, objectives, evaluation and improvement.
ISO/IEC 27001:2022Management-system foundation for information-security risk management.
ISO/IEC 27701:2025Adds a privacy-management layer for organisations processing personal data.
OWASP Top 10 for LLM ApplicationsApplication-level threats: prompt injection, sensitive disclosure, improper output handling, excessive agency and unbounded consumption.
MITRE ATLASA living knowledge base of adversary tactics and techniques against AI-enabled systems.

Framework alignment supports governance and audit readiness. Formal certification, legal assessment and regulatory compliance determinations require the relevant qualified parties.

Figure 02 — Profitec AI assurance lifecycle

Seven stages, each anchored to a reference framework

Govern runs through every stage

01GovernNIST AI RMF
02MapISO 27001
03Threat modelMITRE ATLAS
04Build controlsOWASP GenAI
05EvaluateNIST GenAI Profile
06EvidenceISO 42001
07MonitorNIST CSF 2.0

Framework tags are text labels, not certification marks — they signal which source informs each stage.

The delivery model — seven stages

Stage 1

Establish ownership, purpose and risk boundaries

Every delivery starts with an AI system dossier — what the system is intended to do, who owns it, which business process it supports, which users are affected and which actions it may perform.

Ownership matters because risk acceptance has to be assigned. A marketing assistant that drafts campaign copy has a different action surface from an agent that changes customer records, sends messages or prepares a payment instruction. The latter requires a narrower authority model, formal escalation paths and stronger evidence.

The first workshop produces:

a named business owner and technical owner;
a written system purpose and intended operating context;
a list of permitted and prohibited actions;
a risk classification for the use case;
decision thresholds that require human approval;
a record of systems, data sources and vendors in scope;
success criteria, failure conditions and service-level expectations.

Maps to Govern (NIST AI RMF), Govern (NIST CSF 2.0) and the policy and accountability requirements of ISO/IEC 42001.

Deliverable

AI system dossier — the reference point for architecture, testing, change management and incident response. Updated whenever the system gains a new data source, tool, model, broader permission scope or higher-impact business role.

Stage 2

Map data, identities, integrations and action paths

Security design begins with an accurate picture of how information moves — more than the agent diagram shown in a product demo.

For every component, we document:

data categories, classification and sensitivity;
personal data, confidential business information and regulated records;
data origin, lawful purpose, retention and deletion path;
authentication method, service identity and source-system permissions;
model provider, hosting environment and regional settings;
vector-store tenancy, embedding pipeline and document metadata;
APIs, webhooks, automation platforms and downstream actions;
logging destinations, access to logs and retention of telemetry.

For privacy-sensitive deployments, the map supports data-minimisation decisions: processing only data that is adequate, relevant and limited to what the stated purpose requires. Source selection, chunking rules, retrieval filters and retention policies all affect that assessment.

The design question

What is the minimum data and minimum permission set required for this system to perform its defined task?

The answer shapes the architecture. A knowledge assistant may only need read access to a curated collection. A CRM assistant may need permission to create a draft task while record updates and outbound messages stay behind an approval gate. A reporting workflow can query a read-only warehouse replica, keeping production systems out of scope.

Maps to Map (NIST AI RMF), Identify (NIST CSF 2.0), ISO/IEC 27001 asset and risk management, and ISO/IEC 27701 privacy information management.

Deliverable

Data-flow map and trust-boundary diagram — a visual architecture showing where data enters, is transformed, is stored, who can access it, and which components can act. Every connector has an owner, an identity, a purpose and a permission scope.

Stage 3

Build an AI-specific threat model

Threat modelling turns an architecture diagram into a security plan, covering credible attack paths, system misuse and operational failure modes before deployment. A useful threat scenario contains six elements.

01
Actor
External attacker, malicious insider, compromised vendor, ordinary user or unintended system behaviour.
02
Entry point
Prompt, email, uploaded file, web page, API payload, source document or integration.
03
Precondition
A permission, configuration error, missing filter, vulnerable plugin or uncontrolled data path.
04
Asset at risk
Source content, credentials, customer records, decision integrity, availability or audit evidence.
05
Outcome
Disclosure, unauthorised action, manipulation, service disruption, financial loss or regulatory exposure.
06
Control & detection
Prevention, telemetry, alert and response procedure.

The model should cover direct and indirect prompt injection — where an LLM processes external content, such as a website or file, and that content changes the model's behaviour. In an enterprise workflow this can arrive through a supplier email, a PDF in a shared drive, a support ticket or a retrieved web page.

It should also examine excessive agency, whose three recurring causes are excessive functionality, excessive permissions and excessive autonomy. An agent given a generic high-privilege identity or an open-ended “run command” capability carries a wider blast radius than its business purpose requires. MITRE ATLAS gives a structured vocabulary for adversarial tactics, supports red-team scenario design and connects AI threats to familiar security operations.

Maps to Measure (NIST AI RMF), OWASP LLM Top 10 application threats and MITRE ATLAS adversary techniques.

Deliverable

AI threat model and control backlog — each scenario carries a likelihood and impact rating, an accountable owner, a target control, an implementation priority and a verification method. High-risk scenarios stay visible after launch in the risk register and monitoring plan.

Stage 4

Implement controls at the trust boundaries

The most consequential controls sit outside the model. They determine what data reaches the model, what permissions it receives and which actions can pass into operational systems.

01
Retrieval with the caller's access context
RAG systems apply the user's identity, role, organisation and document entitlement before content reaches the model. Metadata filtering is enforced in the retrieval path, with a tested denial outcome for unauthorised content. A vector database accelerates semantic search; it does not replace the source system's access model.
02
Dedicated identities and minimum necessary permissions
Each agent and integration uses a separate service identity with purpose-limited scopes. Read, write, delete, export and administrative functions are separated wherever the process allows. Expiring tokens, secure secret storage, permission reviews and integration inventories keep a workflow from inheriting broad standing access.
03
Deterministic action controls
A prompt can guide behaviour; authorisation is enforced through application code, policy engines, API gateways and tool contracts. The action layer has a defined schema, validated parameters and explicit rejection paths.
04
Input, output and integration handling
External content — emails, documents, web pages and third-party responses — is treated as untrusted input. Data passed downstream needs output validation, contextual encoding and strict tool schemas. Free-form model output is never passed directly into code execution, query execution or high-impact API requests.
05
Observability and auditability
Each meaningful event is attributable to a user, service identity, model configuration and workflow version. Evidence becomes useful when it connects the request, the retrieved sources, the selected tool, the policy decision, the final action and the result.

For higher-impact actions the workflow requires one or more of:

a user confirmation
a role-based approval
a second deterministic validation
a transaction limit
a review queue
a time-bound permission
a dry-run or draft mode

The approval threshold depends on the business impact of the action, the reversibility of the outcome, the sensitivity of the affected data and the confidence of the underlying evidence.

Maps to Protect (NIST CSF 2.0), ISO/IEC 27001 information-security controls and OWASP guidance for agentic applications. Zero-trust principle: authentication and authorisation are handled as discrete functions before access to a resource is established — which applies directly to AI agents and their tool calls.

Deliverable

Security architecture and control specification — access-control model, service-account register, tool policy, approval matrix, secrets plan, logging specification and documented trust boundaries.

Figure 03 — From prompt to controlled action

Model output reaches operational systems only through deterministic gates

source

Model output

Direct high-impact action — blocked

gate

Policy validation

Allowed action for this caller?

gate

Tool schema validation

Typed parameters, bounds checked

gate

Approval gate

Confirm / escalate by impact

out

Downstream system

CRM, payment, message, ticket

out

Audit log

Request, decision, action, result

The model proposes; deterministic layers dispose. No free-form output reaches a high-impact system directly.

Stage 5

Evaluate the system against failure scenarios

A system is tested against its intended workflows and its credible failure modes. The evaluation set uses examples from actual business processes, sanitised where necessary, with expected outcomes and review criteria.

Test areaWhat the test verifies

Prompt injectionThe system resists attempts to redirect instructions through direct inputs and retrieved content.
Retrieval authorisationUsers only receive content permitted by their source-system entitlement.
Tool safetyThe model cannot invoke unapproved tools, pass invalid parameters or exceed delegated authority.
Action approvalHigh-impact actions pause, escalate or fail safely according to the approval matrix.
Output integrityStructured outputs conform to schema and downstream systems reject unsafe or malformed data.
Change regressionModel, prompt, connector and policy changes preserve prior security and business controls.
Availability & costRate limits, timeouts, retry policy and budget guardrails prevent uncontrolled consumption.
Evidence qualityLogs and traces let an authorised reviewer reconstruct significant actions.

Testing is repeatable. A prompt-injection corpus, a permissions test suite and an action simulation run whenever a high-impact component changes — and the GenAI lifecycle framing encourages weighing legal and regulatory requirements, risk tolerance and resource constraints.

Maps to Measure and Manage (NIST AI RMF), the NIST Generative AI Profile and ISO/IEC 42001 performance evaluation.

Deliverable

Evaluation suite and assurance report — test coverage, acceptance criteria, findings, remediation actions and residual risk. It becomes part of the evidence base for internal review, customer due diligence and future change control.

Stage 6

Assemble evidence as the system is built

Evidence assembled after an incident or a security questionnaire is incomplete by design. Engineering work should generate the records needed to explain the system while it is being designed and operated.

Figure 04 — Evidence pack for enterprise AI

Eight artifacts assembled as the system is built

01
AI system dossier
Purpose, ownership, permitted actions, risk class
02
Data-flow map
Where data enters, moves, is stored, who can act
03
Threat model
Scenarios, likelihood, impact, control path
04
Risk register
Open risks, owners, treatment, residual risk
05
Access model
Identities, scopes, entitlement, approval matrix
06
Evaluation report
Coverage, findings, remediation, acceptance
07
Monitoring plan
Signals, alert criteria, review cadence
08
Incident playbook
Suspend, isolate, revoke, preserve, recover

Assembled continuously — so a reviewer can reconstruct why any result was produced or any action was taken.

The required evidence varies by contract, sector, jurisdiction and organisational role. Framework alignment supports governance and audit readiness; certification, legal assessment and regulatory determinations require the relevant qualified parties.

Maps to ISO/IEC 42001 management-system practices, ISO/IEC 27001 information-security management and ISO/IEC 27701 privacy accountability.

Deliverable

A compliance-ready evidence pack — assembled continuously, version by version, so the organisation can explain any decision the system made.

Stage 7

Monitor, respond and recover

AI systems change after release. A provider can update a model. A connector can expand its scopes. A knowledge base can ingest a sensitive document. A prompt edit can alter tool selection. Each change can affect the risk profile, so the operating model needs recurring reviews and clear triggers for reassessment.

Useful monitoring signals include:

unusual tool-call volume or failed policy checks
attempts to access restricted content
rejected approval requests
unexpected permission changes
source-document ingestion anomalies
changes in retrieval patterns
increased error, timeout or retry rates
repeated unsafe-output blocks
model, prompt and workflow-version changes
customer complaints or material user escalations

The incident playbook defines how to suspend write actions, isolate an integration, revoke credentials, preserve evidence, identify affected records, communicate internally and validate recovery. A practical kill switch can disable an agent's action layer while the wider application stays available in a read-only state. Detect, Respond and Recover are operational capabilities that should be ready before an incident occurs.

Maps to Detect, Respond and Recover (NIST CSF 2.0) and ISO/IEC 42001 continual improvement.

Deliverable

Monitoring plan and incident playbook — a review cadence, alert criteria, escalation contacts, emergency actions and a checklist for reassessment after material changes.

Hidden risks that frequently survive a successful demo

A workflow can pass a product demo and still carry the risks below. Each one sits at a trust boundary the demo never exercised.

Risk board

#RiskExposureControl

01Prompt injectionExposure · Trusted content becomes an instruction channel — a retrieved email, document or page redirects the model.Control · Instruction–data separation, input controls, tool constraints, adversarial testing.
02Excessive agencyExposure · A broad service account becomes the agent's real authority over every model decision.Control · Dedicated identities, scoped API permissions, tool allowlists, approval gates.
03Retrieval leakageExposure · A knowledge base mixes permission models and a user sees unauthorised material.Control · ACL-aware retrieval enforced at query time, with its own tests and telemetry.
04Output to executionExposure · A model response is consumed directly by a workflow runner, SQL layer or messaging tool.Control · Typed schemas, validation, business rules, independent approval paths.
05Vendor configurationExposure · Provider, endpoint, data-use policy, residency, retention and subprocessors shift the risk surface.Control · Repeatable vendor review and a change-monitoring process.
06Evidence gapExposure · The system works for the user but an action cannot be reconstructed afterwards.Control · Version records, source traces, policy-decision and action logs.
07Change invalidates assuranceExposure · A new model, tool schema, source collection or permission alters behaviour.Control · Regression tests and an approval path proportional to the change's impact.

No red warning cards — these are engineering boundaries, each with a defined control, not alarms.

Privacy and regulatory context

AI governance and privacy obligations are deployment-specific. The EU AI Act applies on a phased schedule, and applicability depends on the organisation's role, system category, use case and market. The current legal position should be assessed against the official text and the organisation's circumstances.

Where personal data is involved, privacy review should address purpose, data minimisation, retention, security, data-subject rights, processor arrangements and international transfers. A Data Protection Impact Assessment may be required when processing is likely to result in a high risk to individuals' rights and freedoms. Legal counsel or a qualified privacy professional should determine the applicable obligations.

What a mature AI automation delivery looks like

A mature AI automation project has a traceable chain from business requirement to implemented control:

Business purpose → system scope → data & permission map → threat scenario → architecture control → test case → operational evidence → monitoring & review.

This chain makes it possible to explain the system to an executive sponsor, an internal security team, a privacy officer, a customer security reviewer or an auditor. It also gives engineering teams a practical method for making trade-offs before a workflow reaches production. AI automation earns trust through constrained authority, visible data flows, tested failure handling and accountable operation.

How Profitec AI approaches it

An engineering proof layer under the AI Compliance offering

This delivery model is the engineering layer beneath the commercial offering. The AI Compliance service maps use cases, data exposure, action surfaces and control gaps; the Security & Controls page documents least-privilege access, approval gates, audit logs, secrets and kill switches. This article is the architecture-level proof beneath both.

Systems are designed with reference to NIST AI RMF, ISO/IEC 42001, ISO/IEC 27001 and OWASP GenAI guidance — alignment that documents how governance, security and risk controls were considered, distinct from formal certification or a legal compliance determination.

AI Compliance & Governance Security & Controls

Secure AI automation — frequently asked questions

Does RAG remove prompt-injection risk?

No. RAG can improve access to relevant information, but OWASP states that RAG and fine-tuning do not fully mitigate prompt-injection vulnerabilities. Retrieved content needs the same trust-boundary treatment as any other external input — instruction–data separation, input controls, tool constraints and adversarial testing.

Does every AI agent need human approval?

Approval requirements should follow the impact of the action. Read-only retrieval, low-risk drafting and reversible internal updates can use lighter controls than payment instructions, account changes, outbound communications or records with legal significance, which should pass through an approval gate.

Can a system prompt enforce access control?

No. Access control belongs in deterministic layers — identity providers, application code, policy engines, API gateways and source-system permissions. A system prompt can express behaviour rules; it cannot replace an authorisation boundary.

Does alignment with NIST, ISO or OWASP mean the system is certified or legally compliant?

No. Framework alignment documents how governance, security and risk controls were considered in the system's design and operation. Certification and legal compliance require independent assessment against the applicable standard, law, contract and scope by qualified parties.

When should an organisation review the AI architecture again?

A review should follow material changes: a new model, a major prompt or orchestration change, a new data source, a new connector, expanded permissions, a new user population, a security incident, or a significant change in the business process.

Start here

Start with an AI Compliance Quick Scan

Profitec AI maps AI use cases, data exposure, action surfaces and immediate control gaps before production. The result is a prioritised plan for governance, security controls, evaluation and evidence — the same chain described above, applied to your AI Compliance workflows.

Explore AI Compliance & Governance Request a workflow review View Security & Controls

Standards and source material

External standards open in a new tab. Listed for traceability and verification — alignment with these sources documents how controls were considered and does not by itself constitute certification or a legal compliance determination.