Security & data control

Your company should control the data.Not the AI model.

TEMRIK places a secure AI orchestration and human-control layer between business information and the AI models used to process it. Keep company knowledge, permissions, workflows and evidence under organisational control. Give models only the context required for the task.

The model can change. The company's operating memory should not have to.

Encryption · tenant isolation · scoped model access · auditability · human authority

Company controlled

Business context

  • Business data
  • Documents
  • Policies
  • Playbooks
  • Permissions
  • Decision history

TEMRIK control layer

Policy + context

  • Tenant boundary
  • Identity
  • Policy
  • Context selection
  • Model router
  • Dispatcher Gate
  • Audit record

Replaceable compute

Selected model

  • OpenAI
  • Anthropic
  • Gemini
  • Azure-hosted
  • AWS-hosted
  • Private / open
  • Confidential endpoint

Step 1

Model result

Step 2

TEMRIK policy check

Step 3

Authorised action

Provider names illustrate architectural choice. Availability depends on deployment configuration and does not imply every provider is currently integrated.

The AI security question

The risk is not just where your files are stored.

Once AI can reason across email, accounting, contracts, CRM, projects and internal knowledge, cybersecurity becomes an orchestration problem.

What can this agent see?
Why can it see it?
Which model receives the information?
How much context is actually required?
Which systems can it call?
Can it export information?
Can it take action?
Who approves that action?
What gets stored?
Can we reconstruct what happened?

AI security is no longer only about securing the database.It is about securing the path from information to action.

Company data plane

Keep the intelligence of the business outside the model.

The durable asset is not a chat transcript with a foundation model. It is the organisation's source documents, structured knowledge, workflow state, permissions, business rules, playbooks, evidence, decisions and approved outcomes.

1

Company data

Owned business information remains the source of truth.

2

Permission evaluation

Identity, tenant and role determine what may be retrieved.

3

Minimum necessary context

Only the context required for the task should be assembled.

4

Selected model

A configured compute environment performs the defined reasoning task.

5

Policy + authority

The result is evaluated against rules outside the model.

6

Recorded outcome

Approved actions and evidence remain part of the company system.

Model portability

Today's best model may not be tomorrow's best model.

Model-independent AI orchestration is designed to keep company workflows and policy separate from a single model vendor. Different workloads can justify different models, privacy controls, regions, costs and performance profiles.

ConfigurableProvider dependent

TEMRIK model router

Model A

Selected by workload policy

Model B

Selected by workload policy

Private model

Selected by workload policy

Future model

Selected by workload policy

Model capability, data sensitivity, geography, retention policy, cost and latency can all influence the route.
01

Model choice

Use different compute for different workloads.

02

Model replacement

Move a workflow when capability, price or privacy changes.

03

Reduced lock-in

Keep rules and company knowledge outside provider-specific prompts where practical.

04

Workload routing

Match the security boundary to the sensitivity of the work.

05

Resilience

Avoid treating one provider as the entire operating architecture.

Context control

The safest document is sometimes the document the model never receives.

Least-privilege AI begins before encryption. TEMRIK's design direction is to identify the user, workflow and permissions first, retrieve only relevant sources, then assemble the minimum useful context.

Identity
Role
Workflow
Permission

Minimum necessary context

A subcontractor-variation workflow may need the relevant contract clause, instruction, drawing revision, claimed amount and programme impact. It probably does not need payroll, unrelated legal files, every company email, unrelated projects or HR records.

Query + relevant sources + approved permissions → selected model

Confidential AI

Protect data while it is stored. Protect it while it travels. Then protect it while it computes.

01Live control

At rest

Information sitting in databases, object storage, indexes and backups.

  • Encrypted storage
  • Access control
  • Tenant boundaries
  • Key-management options
02Live control

In transit

Information moving between users, TEMRIK, integrations and approved AI services.

  • Encrypted connections
  • Authenticated services
  • Controlled endpoints
  • Transport security
03Architecture path

In use

Information actively being processed by CPUs and GPUs.

  • Trusted Execution Environments
  • Confidential virtual machines
  • Encrypted compute memory
  • Hardware attestation
The Confidential Computing Consortium defines confidential computing as protection of data in use by performing computation inside a hardware-based, attested Trusted Execution Environment. This is distinct from ordinary transport encryption or a provider's retention policy.

The direction of travel

Meta Private Processing · public reference architecture

Private AI computation is moving from theory into infrastructure.

Meta has publicly described Private Processing as confidential-computing infrastructure for AI workloads, using confidential virtual machines, hardware-backed memory protection and remote attestation. Its published architecture demonstrates one emerging model for protecting cloud AI data while it is actively processed.

TEMRIK is not affiliated with Meta and does not claim to use Meta infrastructure. The example is included to show where the wider confidential-computing industry is heading.

Read Meta's published architecture

Publicly documented design elements

Trusted Execution Environments
Confidential virtual machines
Encrypted memory
Remote attestation
Ephemeral session keys
Restricted administrator access
Verifiable software measurements
Encrypted client-to-confidential-runtime requests

Choose the compute boundary

Different workloads can justify different AI environments.

Major enterprise AI providers offer different combinations of no-training commitments, retention controls, customer-managed keys, private networking, geography controls and confidential-compute features. TEMRIK's role is to make those provider choices part of policy rather than invisible implementation detail.

Provider dependent

Standard enterprise AI

Approved provider, scoped context, encrypted transport.

Provider dependent

Zero-retention AI

Eligible services configured to minimise or eliminate provider retention.

Configurable

Customer-cloud AI

Customer-controlled cloud resources, identity and networking where supported.

Configurable

Private model

Dedicated or customer-hosted model endpoint for selected workloads.

Architecture path

Confidential inference

Hardware-attested TEE/CVM boundary for data in use.

Clear language

Encryption, zero retention and confidential processing are different controls.

Encryption in transit

Protects data while travelling across networks.

Zero data retention

Addresses whether eligible request content is retained after processing.

Customer-managed keys

Give customers additional control over keys for supported stored data.

Confidential computing

Protects data in use inside a hardware-enforced trusted environment.

True end-to-end encryption

Requires plaintext to remain unavailable to intermediaries outside the defined trusted endpoints.

TEMRIK does not describe an ordinary commercial LLM API as “end-to-end encrypted” merely because TLS is used. Precise language matters because each control addresses a different part of the risk.

Secure the control plane

The model is only one component of the risk.

The control plane determines what the model may know, which tools it may use, and whether a generated recommendation can become a real-world action.

Identity

Who is asking?

Tenant

Which organisation owns the context?

Role

What is this person or agent permitted to access?

Context

Which information is actually relevant?

Model

Which compute environment is authorised?

Tools

What systems may the model call?

Action

What may it prepare or propose?

Authority

Who must approve consequential release?

Audit

What evidence should remain afterwards?

Agents need boundaries

An AI that can act needs more controls than an AI that can answer.

OWASP's current GenAI security work highlights prompt injection, sensitive-information disclosure, supply-chain risk, improper output handling and excessive agency. These are orchestration problems as much as model problems.

Prompt injection
Sensitive-data disclosure
Excessive agency
Tool misuse
Compromised agent identity
Poisoned external context
Insecure tool/MCP supply chain
Privilege escalation

The AI does not define its own permissions

1

Untrusted input

Treat instructions and external content as data, not authority.

2

TEMRIK context control

Select sources through identity, tenant and workflow rules.

3

Model

Generate analysis or a proposed action.

4

Untrusted output

A confident answer is still not an authorisation token.

5

TEMRIK policy control

Evaluate tool access, scope and release conditions deterministically.

6

Human authority

Require an authorised person where the consequence demands it.

7

Action + audit

Release only the approved scope and retain the evidence.

The LLM should never be the security policy.

One controlled stack

The model sits inside the operating architecture. The operating architecture does not sit inside the model.

Layer 7

Auditable action

Decision · evidence · actor · time · outcome

Layer 6

Human control

Dispatcher Gate · approval · escalation

Layer 5

Agent + tool policy

Allowed tools · scope · limits · exceptions

Layer 4

Model router

Selected LLM · provider policy · private inference

Layer 3

TEMRIK knowledge + playbooks

Retrieval · rules · process · evidence

Layer 2

Identity + tenant boundary

Authentication · organisation · role · permission

Layer 1

Company data

Documents · systems · records · knowledge

Change the model

Model-centric architecture

The business gets built around one provider.

Company
One AI provider
Provider-specific prompts
Provider-specific workflow

Company-centric architecture

The provider becomes a replaceable compute component.

Company data
Business rules
Playbooks
Permissions
Human authority
Model A / B / private

Change the model. Keep the business.

Security modes

Apply stronger boundaries as the sensitivity and consequence increase.

01Live control

Standard controlled AI

  • Tenant controls
  • Scoped context
  • Enterprise provider
  • Encrypted transport
  • Audit history
  • Human authority
02Configurable

Restricted data workflow

  • Narrower context
  • Retention controls
  • Regional requirements
  • Stricter tool permissions
03Provider dependent

Private cloud / customer environment

  • Customer cloud resources
  • Private networking
  • Customer-managed keys
  • Enterprise identity
04Architecture path

Confidential inference

  • Hardware TEE
  • Attestation
  • Encrypted memory
  • Ephemeral processing

Exact controls depend on customer requirements, provider capabilities and the agreed implementation architecture.

Security can begin before encryption

What TEMRIK should not send matters as much as how it is encrypted.

01

Do not send 30 documents when two paragraphs are sufficient.

02

Do not expose HR records to a construction variation workflow.

03

Do not expose every project to a user authorised for one project.

04

Do not put passwords or API credentials into system prompts.

05

Do not give an AI payment authority merely because it can calculate an invoice.

06

Do not treat generated output as proof of authority.

07

Do not let an external document silently redefine an agent's permissions.

08

Do not connect a tool without defining what the tool is allowed to do.

Human control remains

Security controls what AI can reach. Human control decides what AI can release.

TEMRIK's existing human-control architecture separates preparation from permission. Data access, model access, tools and proposed actions can all be controlled before a consequential external action is released.

Data accessControlled
Model accessControlled
ToolsControlled
Proposed actionControlled
Consequential releaseAuthorised person

Questions worth asking

Bring your current AI architecture. We'll start with the boundary.

Where does your AI knowledge live?
Which provider can currently see prompts?
Are prompts retained?
Are they used for training?
Can your company change providers?
Who controls encryption keys?
Can one team see another team's context?
Can an AI agent call external systems?
Can an AI send information outside the company?
Can the model approve its own action?
Can you reconstruct what it saw?
Can access be revoked immediately?
What happens when a provider goes down?
What happens when a better model appears?
Which workflows genuinely require confidential compute?

Security by workflow

Not every workflow needs the same boundary.

A public FAQ assistant does not necessarily need the same security environment as legal analysis, financial records, board material, employee information, confidential project information, intellectual property or acquisition documents.

Data sensitivity × action consequence × regulatory requirement × model requirement

Low sensitivity / low consequence

Standard controlled AI may be sufficient.

Low sensitivity / high consequence

Stronger action controls and explicit authority.

High sensitivity / low consequence

Narrow context, retention and provider controls.

High sensitivity / high consequence

Strongest available data and action boundary; consider private or confidential compute.

TEMRIK security principles

01

The company owns the context.

02

The model receives only what it needs.

03

The model is replaceable.

04

Permissions live outside the prompt.

05

Generating is not authorising.

06

Tools have defined scope.

07

Higher-risk work requires stronger boundaries.

08

Important actions remain auditable.

09

Humans retain consequential authority.

10

Security should improve as confidential compute matures.

Where this is heading

AI infrastructure is moving toward verifiable private computation.

The likely enterprise pattern combines organisation-controlled data stores, identity-aware retrieval, model routing, least-privilege tools, confidential computing, attestation, retention controls, human authority and verifiable audit records.

TEMRIK's strategic position

The TEMRIK control plane between enterprise data, AI models, agents and authorised action.

Live controlConfigurableProvider dependentArchitecture path

The foundation model will change.Your company's operating memory should not have to.

Free field guide

27 Rules of Peace

Security is stronger when the operating rules are clear before AI enters the workflow.

Download TEMRIK's free construction AI field guide on decision rights, controlled escalation, evidence, playbooks and keeping people in authority when AI is involved.

Get the free ebook

Free guide · opens the TEMRIK Peace download page.

Control before scale

Before you give AI more of your business, decide what it is allowed to know.

TEMRIK can help map one workflow, its data, model access, permissions, actions and approval boundary before AI is scaled across the organisation.

No certification, confidential-inference availability or universal model compatibility is claimed by this page. Production controls depend on the selected provider, customer requirements and implementation scope.

The model can change.Your data, your rules, your knowledge and your authority stay with the business.