A practical architecture for securing contracts, invoices, employee data, and business documents before they are consumed by AI models, document intelligence systems, and enterprise agents.
Organizations are rapidly building AI-powered applications on top of business documents such as contracts, invoices, employee records, financial reports, sales data, and operational data. While significant effort is spent on developing AI models and intelligent agents, security is often treated as an afterthought.
One of the biggest risks in enterprise AI is exposing sensitive information during document storage, processing, and retrieval. Simply storing files in cloud storage or data platforms is not enough. The data should also be secured during transmission.
In this article, I will walk you through a security-first architecture that combines AES encryption, Azure Key Vault, Service Principals, RBAC permissions, and controlled decryption workflows to protect sensitive documents while still enabling AI-powered document extraction, analytics, and intelligent agents.
We’ll cover:
✔ The security problem enterprises face
✔ Why encrypted storage alone is not enough
✔ Why encryption keys should never be stored in code or .env files
✔ Azure Key Vault fundamentals
✔ Service Principal authentication
✔ RBAC permissions and access control
✔ Creating and managing Key Vault secrets
✔ Python implementation examples
✔ Snowflake and Databricks integration patterns
✔ Secure document processing for AI workloads
✔ Security benefits and best practices
This architecture can be applied across Snowflake, Databricks, Microsoft Fabric, Azure AI Foundry, Synapse Analytics, and custom AI platforms.
The Growing Security Challenge in Enterprise AI
Organizations are increasingly building AI applications on top of business-critical documents.
Examples include:
- Customer contracts
- Legal agreements
- Invoices
- Financial statements
- Employee records
- Payroll information
- Vendor documents
- HR reports
- Employee attrition predictions
- Compliance reports
- Healthcare records
- Procurement documents
These documents often contain highly sensitive information.
At the same time, organizations want AI systems to:
- Extract information from documents
- Build search experiences
- Power RAG solutions
- Support AI agents
- Generate business insights
- Answer natural language questions
- Generate KPIs, charts and visuals
- This creates a difficult challenge:
How can we allow AI systems to use sensitive information without exposing the underlying documents?
The Wrong Approach
Many organizations unknowingly introduce security risks by:
- Storing documents unencrypted
- Storing encryption keys in source code or environment files
- Keeping secrets in configuration files
- Saving credentials inside notebooks
- Embedding keys inside ETL pipelines
For example:
AES_KEY = "MySecretEncryptionKey"
If someone gains access to:
- GitHub repositories
- DevOps pipelines
- Virtual machines
- Databases
- Storage accounts they may gain access to both the encrypted documents and the encryption key.
At that point, encryption provides little value.
The Security Principle
One of the most important security principles is:
Encrypt the data and protect the encryption key separately.
Even if attackers gain access to encrypted documents, they should not be able to access the encryption key.
This is where Azure Key Vault becomes critical.
The Solution Architecture
The architecture consists of five major layers:
- Document Encryption
- Secure Key Storage
- Controlled Authentication
- In-Memory Decryption
- AI Processing
Document Source — The source of document can be anything like SAP, Cloud storage, Azure Blob Storage etc.
When we move them to our storage layer, they should be encrypted.
Step-by-Step implementation guide-
A) Why We Encrypt Documents
Consider documents such as:
- Client contracts
- Employee compensation data
- Vendor agreements
- Invoices
- Strategic business reports
- Attrition prediction outputs These files often contain information that should not be accessible to every user or system.
Before storing these files, we encrypt them using AES-256.
This ensures that even if storage is compromised or a developer has RBAC (Role based access control), the document remains unreadable without the encryption key.
B) Creating an AES Encryption Key
Example:
from Crypto.Random import get_random_bytes
AES-256 = 32 bytes
aes_key = get_random_bytes(32)
print(aes_key.hex()) 32 bytes = 256 bits
This creates an AES-256 encryption key.
Why AES?
AES (Advanced Encryption Standard) is one of the most widely used symmetric encryption algorithms in the world.
Advantages:
- Fast
- Highly secure
- Industry standard
- Suitable for large documents
- Supported across cloud platforms AES-256 is commonly used in enterprise environments.
C) What is Azure Key Vault?
Azure Key Vault is a managed Azure service designed for securely storing and controlling access to secrets, cryptographic keys, and certificates.
Instead of storing sensitive values in application code, organizations place them inside a centralized vault protected by Azure Identity and RBAC controls.
Azure Key Vault supports three primary object types:
Secrets
Examples:
- API Keys
- Database Passwords
- OAuth Client Secrets
- AES Encryption Keys
Keys
Examples:
- RSA Keys
- Cryptographic Signing Keys
- Customer Managed Encryption Keys
Certificates
Examples:
- SSL Certificates
- TLS Certificates
In our use case, the AES encryption key is stored as a Secret.
Why Azure Key Vault is required?
- Centralized secret management
- Fine-grained access control
- Secret rotation support
- Access auditing
- Compliance support
- Reduced insider risk
Creating Azure Key Vault
1.Navigate to: portal.azure.com
Azure Portal -> Create Resource -> Key Vault -> Create
2.Configure:
Subscription
Resource Group
Region (eg. Central India)
Vault Name (eg. projectname-aes-key-kv)
3.For Authorization/Permission Model:
Select: Azure Role Based Access Control (RBAC)
4.For Networking:
Public access: Selected networks
or
Private endpoint
5.Permissions Required to Create a Key Vault
Typically one of the following roles:
- Owner
- Contributor
- Key Vault Contributor
Important:
Key Vault Contributor can manage the Key Vault resource itself but cannot read secrets stored within the vault.
This separation improves security.
*6.Storing the AES Key in key vault secrets and the permissions that are required to create secrets.
*
IMP: When using Azure RBAC, you will need Key Vault secret officer role to create secret.
Once the role is assigned, Create and Store the generated AES key as a secret.
Example:
Secret Name:
AES-DOCUMENT-ENCRYPTION-KEY : secret _code
The key is now centrally managed and protected.
D) Creating a Service Principal Applications, requires an identity to access Azure resources.
This is where Service Principals are used.
Think of a Service Principal as:
A non-human identity used by applications.
Example:
Snowflake/Databricks/Azure Function/Fabric Pipeline/Custom API
↓
Service Principal
↓
Azure Key Vault
↓
AES Secret
The Service Principal becomes the trusted identity that accesses the vault.
Why Service Principals Are Important
Without Service Principals:
- Applications would require user credentials
- Automation becomes difficult
- Auditing becomes harder
Service Principals provide:
- Automated authentication
- Secure access
- RBAC integration
- Least privilege access
Required: The service principal system-managed identity must be assigned read secret role on the key vault
For Snowflake, Databricks, Fabric, or AI platforms: (Your service principal name might be: projectname_aeskey_extract_spn)
Assign Role:
Key Vault Secrets User
Can:
- Read secret values
- Read secret metadata
E) Python Example: Reading the AES Key
from azure.identity import ClientSecretCredential
from azure.keyvault.secrets import SecretClient
credential = ClientSecretCredential(
tenant_id="<tenant-id>",
client_id="<client-id>",
client_secret="<client-secret>"
)
vault_url = "https://company-kv.vault.azure.net"
client = SecretClient(
vault_url=vault_url,
credential=credential
)
aes_key = client.get_secret(
"AES-DOCUMENT-ENCRYPTION-KEY"
).value
The application retrieves the key only when needed.
F) Encrypting Sensitive Documents
from Crypto.Cipher import AES
from Crypto.Util.Padding import pad
from Crypto.Random import get_random_bytes
# AES key retrieved from Azure Key Vault
key = bytes.fromhex(aes_key_hex)
# Generate random IV (16 bytes for AES)
iv = get_random_bytes(16)
with open("contract.pdf", "rb") as file:
plaintext = file.read()
cipher = AES.new(key, AES.MODE_CBC, iv)
ciphertext = cipher.encrypt(
pad(plaintext, AES.block_size)
)
# Store IV along with encrypted content
encrypted_content = {
"iv": iv,
"ciphertext": ciphertext
}
The encrypted file can now be stored safely.
G) AI Processing Pattern
When processing begins:
- Retrieve AES key from Key Vault
- Decrypt document in memory
- Extract structured or unstructured chunk information
- Persist extracted results
- Discard decrypted content
The key principle is:
Decrypt only when required and only in memory.
H) Platform Integration Examples
I) AI Agents and RAG Systems
Once document information is extracted into structured datasets, AI systems can answer questions such as:
- Which contracts expire next month?
- Which invoices exceed $100,000?
- Which vendors require renewal?
- What is the predicted attrition risk for the Sales department?
- Which customers have pending obligations? The AI model operates on structured business data rather than unrestricted access to sensitive raw documents.
J) Security Benefits Achieved
This architecture provides:
- Encryption at Rest — Documents remain protected in storage.
- Key Separation — Encryption keys are separated from encrypted data.
- Least Privilege Access — Applications receive only required permissions.
- Auditing — Secret access can be monitored.
- Key Rotation — Encryption keys can be replaced centrally.
- Compliance Support — Supports enterprise governance and security requirements.
- Reduced Attack Surface — Compromised storage does not automatically expose sensitive information.
Final Thoughts
As organizations accelerate AI adoption, securing the data feeding those AI systems becomes just as important as building the models themselves.
A secure AI platform is not only about model accuracy, vector databases, or intelligent agents. It is equally about protecting contracts, invoices, employee information, and other sensitive business assets that power those systems.
By combining AES encryption, Azure Key Vault, Service Principals, RBAC permissions, and controlled in-memory decryption, organizations can build AI platforms that are secure, scalable, compliant, and enterprise-ready.
The goal is simple:
Protect the documents.
Protect the keys.
Allow AI access only when necessary.
What next?
In my next article, I will walk you through how we implemented enterprise-grade access controls for AI-powered platforms using techniques such as:
- Row-Level Security (RLS)
- Row Access Policies
- Dynamic Data Masking
- Role-Based Access Control (RBAC)
- Business Unit-based filtering
- Customer-based entitlements
- Financial data masking
- Secure document access controls
- Time-limited document download links
- Agent-level authorization patterns
- Governance frameworks for AI applications
We’ll explore how an AI agent can return different answers to different users for the same question, while ensuring that sensitive information remains protected and compliant with organizational policies.
Because securing the documents is important.
But securing who can access the information extracted from those documents is what truly makes an AI platform enterprise-ready.
Top comments (0)