Enterprise AI agent architecture: security

Short answer: enterprise AI agent architecture separates the model, data, tools and execution. Permissions are enforced outside the model, with least privilege, parameter validation and approval for sensitive actions. Production also requires representative evaluations, an accountable owner, supervision and execution budgets. Start with the authorised task, not the most autonomous framework available.

Definition: AI agent architecture. The organisation of a model, sources, tools and execution rules so that the system acts only within an authorised scope.

An agent that finds a contract does not create the same risk as one that edits or sends it. Yet both capabilities can share a chat interface. The first architecture decision should therefore be the scope of action, not the model.

Chatbot, workflow or agent: how much complexity?

This is a design recommendation, not a regulatory classification. An agentic loop needs a measurable benefit: broader request coverage, fewer manual exceptions or shorter handling time. A stable rule does not need to be replaced by a model.

OWASP describes excessive agency as a risk created by too much functionality, permission or freedom of execution. It recommends narrow tools and downstream authorisation. OWASP: Excessive Agency

Which reference architecture should you use?

For an agent that prepares cases without committing the company, we propose the following path. It is an illustrative architecture, not a customer deployment claim.

Authenticated user
  -> Application API: identity, scope, budget
  -> Orchestrator: state and authorised steps
  -> Model: extraction, summary, proposal
  -> Tool gateway: schema, rights, parameters
  -> Human approval when required
  -> Business API: execution and result

The model proposes. Application code decides whether the proposal may run. The target system checks rights on the resource. Evaluation, secrets, persistent state, alerts and stopping are cross-cutting services.

Think of a colleague with a set of keys. Understanding a request does not grant permission to open every door. Controls must remain effective even when the colleague misreads a document.

Separate knowledge from action

Document retrieval and case updates should not automatically inherit the same permissions. Retrieval-augmented generation (RAG) does not replace access control. Filter sources by user before providing them to the model, then test cross-team access attempts.

Our RAG vs GraphRAG guide helps select a retrieval approach. That decision does not remove the need to authorise retrieved documents and derived information.

Give precise tools

Prefer create_draft(case_id, text) to general access that can send any message. A bounded status-update API is preferable to a SQL connection with broad write permissions when that narrow change is all the task requires.

How should permissions and approvals work?

Approval should not cover only an intent such as “process the case”. Show the actual action, target and parameters. If content or recipient changes, the earlier approval is no longer sufficient. OWASP includes action-specific approval for consequential operations. OWASP: Prompt Injection Prevention

An interruption must not create a second send. Use persistent execution state and idempotency keys to recognise operations already performed. See our guide to human approval for AI agents.

How do you limit injection and data leaks?

A retrieved document may contain malicious instructions. Indirect prompt injection tries to turn those data into commands. A filter alone is not enough: tools must enforce permissions independently of the model's response. OWASP: Prompt Injection Prevention

1. Treat external inputs as untrusted.
2. Separate application instructions from documents.
3. Validate tool arguments.
4. Restrict resources and network destinations.
5. Approve sensitive operations before execution.
6. Test attacks in attachments, searches and API responses.

Logs should support operations without copying every document. Case identifiers, model versions, tool names and authorisation decisions may be sufficient, depending on the need. Exclude secrets and unnecessary sensitive content, and protect the traces themselves.

How do you assess quality and cost?

A model benchmark does not validate the complete system. Evaluate normal, incomplete, contradictory and adversarial cases against criteria set before the pilot.

Good writing does not offset forbidden access. Full cost includes models, retrieval, tools, infrastructure, human review and support. Also limit steps, duration, retries and spend per task. Exceeding a budget should cause a controlled stop or escalation.

Keep tool schemas, tests and policies outside the model provider. A model change remains an evaluation project, but need not become a complete workflow rebuild. See evaluating an AI agent before launch.

What should you check before production?

• A business owner and technical owner are named.
• Authorised data and actions are documented.
• Rights are enforced outside the model and tested.
• Approvals, duplicates and interruptions are handled.
• Budgets, alerts and loop limits are active.
• Stopping and degraded operation have been tested.
• Model changes trigger a new evaluation.

The CNIL, France's data protection authority, recommends effective, lasting means of human intervention, including changing a decision or stopping a system where necessary. CNIL: Using AI in production, in French

Complete the review with the production readiness checklist and the POC-to-production roadmap.

Frame an operable agent

Elia Studio builds tailored AI agents, runs opportunity audits and designs sovereign roadmaps. Start with a scope decision: which tasks, data, permissions and evidence are required before production? Contact Elia Studio to frame it.

Sources reviewed on 28 October 2026. Architecture and matrices are illustrative; no customer results are claimed.