Enterprise AI Platforms

Secure AI Beyond the Content Filter

Place enforceable identity, document authorization, untrusted evidence and least-privilege tool boundaries around an enterprise LLM.

Reference architecture - illustrative, not a client deployment

Expose identity, data access and tool-execution boundaries.

Complexity
Advanced
Drawing
Supplied
  • AI Security
  • Authorization
  • Prompt Injection
  • Least Privilege

Overview

This reference architecture is illustrative. It is not a record of a client deployment.

Content filtering is one control, not an authorization system. A secure enterprise AI path starts with authenticated identity and application authorization. Retrieval then enforces document permissions before protected content reaches the model. Even authorized content remains untrusted input: a retrieved document can contain instructions intended to manipulate the model.

The model may answer directly or propose a tool action, but it does not grant itself permission. A deterministic policy boundary validates the caller, operation, resource scope and any required approval. The business API receives narrowly scoped credentials from managed identity or a secret store; credentials never appear in prompt text. The response records a redacted outcome for audit without copying sensitive prompts or secrets into telemetry.

A concrete example

An employee asks an assistant to summarize a permitted procurement document. A hidden paragraph says to send all bids to an external address. Retrieval is allowed, but the text is treated as evidence rather than authority. The model's proposed send action reaches the tool policy, which blocks it because the user lacks that operation and destination. The denied action is logged without storing document contents.

Common misconception

"A private endpoint and content filter make the application compliant." Network isolation and filtering reduce specific risks. They do not prove correct identity, document authorization, least-privilege execution, retention or regulatory compliance.

Diagram & Walkthrough

Choose a declared scenario and step, or select a component by pointer, touch or keyboard. Playback starts only when you press Play and pauses when this panel leaves the screen.

100%
Secure AI Beyond the Content Filter Identity, document authorization and tool execution are separate security boundaries. Retrieved evidence remains untrusted, secrets stay outside prompts, and proposed tool actions require deterministic policy checks before least-privilege execution. Secure AI Beyond the Content Filter Expose identity, data access and tool-execution boundaries. IDENTITY + AUTHORIZATION UNTRUSTED EVIDENCE + INFERENCE CONTROLLED ACTIONS Authenticated identity Authorized principal + query Enforceddocumentpermissions Authorized butuntrusted content Proposed toolaction Scoped credentials,never prompt text Authorized approved call Observed actionoutcome Answer without atool action Access denied · no retrieval Unapproved actionblocked Outcome + safe trace User + Entra ID sign-in HUMAN Application authorization DETERMINISTIC Document-level accessenforcement DETERMINISTIC Protected sourcedocuments DATA LLM with untrustedevidence MODEL · UNTRUSTED OUTPUT Tool policy +approval boundary DETERMINISTIC Least-privilegebusiness API EXTERNAL Managed identityor secret store NEVER IN PROMPT Answer ordenied action EXPLICIT OUTCOME Redacted audit trail DATA Main data Control Feedback Blocked Filters do not replace authorization. Private networking is one control, not a compliance certificate.

Main walkthrough, step 1 of 6: Authenticate and authorize. idle.

Main walkthrough

The primary path through this reference architecture.

Active parts: User + Entra ID sign-in, Application authorization, Document-level access enforcement

Text walkthrough

This vertical reference remains readable without the interactive controls.

  1. 01Authenticate and authorize

    Derive application permissions from trusted identity before reaching protected data.

    Active parts: User + Entra ID sign-in, Application authorization, Document-level access enforcement

  2. 02Enforce source permissions

    Apply document-level permissions and pass only permitted content to the model.

    Active parts: Document-level access enforcement, Protected source documents, LLM with untrusted evidence

  3. 03Treat retrieved text as untrusted

    The model can propose an action from evidence, but the proposal has no execution authority.

    Active parts: LLM with untrusted evidence, Tool policy + approval boundary

  4. 04Keep credentials out of model context

    Deliver scoped credentials directly from managed identity or a secret store to the API boundary.

    Active parts: Managed identity or secret store, Least-privilege business API

  5. 05Enforce tool permissions

    Authorize the proposed call independently and return only its observed outcome.

    Active parts: Tool policy + approval boundary, Least-privilege business API, Answer or denied action

  6. 06Return or deny and audit

    Return a direct answer or block an unauthorized action, then record a minimized audit trail.

    Active parts: LLM with untrusted evidence, Tool policy + approval boundary, Answer or denied action, Redacted audit trail

Connections

  • Authenticated identityUser + Entra ID sign-in to Application authorizationdata
  • Authorized principal + queryApplication authorization to Document-level access enforcementcontrol
  • Enforced document permissionsDocument-level access enforcement to Protected source documentscontrol
  • Authorized but untrusted contentProtected source documents to LLM with untrusted evidencedata
  • Proposed tool actionLLM with untrusted evidence to Tool policy + approval boundarydata
  • Scoped credentials, never prompt textManaged identity or secret store to Least-privilege business APIcontrol
  • Authorized approved callTool policy + approval boundary to Least-privilege business APIcontrol
  • Observed action outcomeLeast-privilege business API to Answer or denied actiondata
  • Answer without a tool actionLLM with untrusted evidence to Answer or denied actiondata
  • Access deniedApplication authorization to Answer or denied actioncontrol
  • Unapproved action blockedTool policy + approval boundary to Answer or denied actioncontrol
  • Outcome + safe traceAnswer or denied action to Redacted audit trailfeedback

Components

User + Entra ID sign-inhuman

Starts a request in an authenticated identity context without granting access by identity alone.

Responsibilities

  • Authenticate through the enterprise identity provider

Inputs

  • Sign-in credentials and factors

Outputs

  • Authenticated identity claims
  • User request

Risks

  • Compromised account
  • Stale group membership
Application authorizationdeterministic

Maps trusted claims and the requested operation to application-level access decisions.

Responsibilities

  • Deny unauthorized requests before protected data access

Inputs

  • Authenticated identity
  • Request
  • Application policy

Outputs

  • Authorized principal and query
  • Access denial

Risks

  • Overbroad roles
  • Trusting caller-supplied group names
Document-level access enforcementdeterministic

Applies source-level permissions so only documents allowed for the caller can become evidence.

Responsibilities

  • Enforce permissions on every retrieval and preserve source identity

Inputs

  • Authorized principal
  • Query
  • Permission metadata

Outputs

  • Authorized document request

Risks

  • Permission synchronization lag
  • Missing filter enforcement
Protected source documentsdata

Holds governed enterprise content and its permission, classification and provenance metadata.

Responsibilities

  • Return permitted source content with traceable metadata

Inputs

  • Protected content
  • Access-control metadata

Outputs

  • Authorized but untrusted evidence

Risks

  • Malicious embedded instructions
  • Stale access metadata
LLM with untrusted evidencemodel

Generates an answer or proposes an action while treating retrieved content as untrusted data, not authority.

Responsibilities

  • Use evidence without directly executing its instructions

Inputs

  • User request
  • Authorized evidence

Outputs

  • Direct answer
  • Proposed tool action

Risks

  • Indirect prompt injection
  • Unsupported claims
Tool policy + approval boundarydeterministic

Re-authorizes every proposed action against caller, operation, resource scope and approval rules.

Responsibilities

  • Approve only allowed calls and block policy violations

Inputs

  • Proposed action
  • Trusted identity
  • Tool policy
  • Optional human approval

Outputs

  • Authorized call
  • Blocked action

Risks

  • Incomplete policy rules
  • Approval fatigue
Least-privilege business APIexternal

Performs one bounded business operation using independently scoped credentials.

Responsibilities

  • Validate inputs and enforce its own authorization and idempotency

Inputs

  • Authorized approved call
  • Scoped credentials

Outputs

  • Observed action outcome

Risks

  • Excessive API permissions
  • Irreversible side effects
Managed identity or secret storedata

Supplies scoped credentials directly to the business API boundary, never through model context.

Responsibilities

  • Protect, rotate and scope machine credentials

Inputs

  • Identity configuration
  • Secret lifecycle policy

Outputs

  • Short-lived or managed credentials

Risks

  • Overprivileged identity
  • Secret exposure in logs
Answer or denied actionexternal

Returns a direct answer, an observed tool outcome or an explicit access or action denial.

Responsibilities

  • Represent the enforced outcome without fabricating success

Inputs

  • Model answer
  • Tool result
  • Policy denial

Outputs

  • User-visible response

Risks

  • Misleading success message
  • Sensitive error detail
Redacted audit traildata

Records identity, policy decision, resource and outcome metadata while minimizing sensitive content.

Responsibilities

  • Support investigation and accountability under retention controls

Inputs

  • Outcome and safe trace metadata

Outputs

  • Controlled audit records

Risks

  • Prompt or secret leakage
  • Audit gaps

Scenario reference

Access denied

Unauthorized requests do not reach protected documents.

  1. 01Deny before retrieval

    The authenticated request fails application authorization, returns a denial and records the safe outcome.

    Active parts: User + Entra ID sign-in, Application authorization, Answer or denied action, Redacted audit trail

Malicious retrieved instruction

Illustrate a blocked unauthorized action, not a guarantee that all prompt injections can be prevented.

  1. 01Block the injected action

    Authorized evidence contains a malicious instruction; the model proposes it, but deterministic tool policy blocks and audits it.

    Active parts: Document-level access enforcement, Protected source documents, LLM with untrusted evidence, Tool policy + approval boundary, Answer or denied action, Redacted audit trail

Design Decisions

  • Derive authorization from trusted identity claims, not user-provided group names.
  • Enforce source permissions before model context assembly.
  • Treat model output as a proposal and re-authorize every business action.
  • Keep credentials outside model context and minimize audit payloads.

Risks & Trade-offs

Permission synchronization can become stale. Retrieved prompt injection remains a residual risk, and policy rules can be incomplete. Excessive logging leaks data; insufficient logging weakens investigation. Human approval reduces automation and is only useful when reviewers receive clear, bounded evidence.

When to Use / Not Use

Use these boundaries whenever an LLM handles protected content or can invoke business APIs. Do not expose high-impact tools when actions cannot be independently authorized and reversed. For deterministic access or workflow rules, call conventional policy and application logic directly instead of asking a model to decide.

Sources