Security, Privacy, and Compliance

Large Language Models (LLMs) open up powerful new capabilities — but they also introduce complex, often invisible security challenges.

You’re no longer securing static databases or predictable APIs.

You’re managing systems that:

• Respond to user prompts with probabilistic outputs
• Make dynamic tool calls with data access implications
• Reason across user input, private documents, and model memory

This section breaks down what makes LLM systems uniquely difficult to secure, and how Orcaworks is designed to close those gaps.

The Hidden Security Threats in LLM Systems

From a CTO’s perspective, the challenge is deceptively simple.

Give your users access to knowledge, without leaking sensitive data.

But LLM systems introduce a new surface area that behaves differently:

• Users prompt systems with unstructured text — possibly leaking sensitive data
• Agents dynamically call tools, retrieve documents, and reason — often without user-specific context
• LLMs return probabilistic outputs — not deterministic responses

Your traditional security model breaks down when:

• The agent doesn’t know which user is behind the prompt
• The vector database doesn’t enforce access filters
• The output includes information the user shouldn’t see

You are now operating in an environment where access control must extend to search.

Content generation must be monitored like a database query.

Orcaworks is designed to bridge this gap.

User Context Is Often Lost

Agent frameworks today (like LangChain, Autogen, CrewAI) rarely maintain a persistent concept of:

• Who the user is
• What roles or permissions they have
• What data they’re allowed to query

This means you risk:

• Leaking data from one tenant to another
• Letting unprivileged users see restricted outputs
• Generating responses with untraceable provenance

Orcaworks solves this by enforcing user identity propagation across all agent steps and data access calls.

Search Is a Security Boundary

Your raw company data becomes AI-searchable after ingestion.

But critical questions remain:

• Who owns that data?
• Who’s allowed to query it?
• What filters or redactions should apply?

Every vector search must be scoped to the user’s permissions.

LLMs Are Probabilistic, Not Deterministic

Even with good access control, there’s no guarantee the LLM won’t:

• Mention confidential terms from a prior conversation
• Parrot back unseen training data
• Infer relationships that feel like data leaks

That’s why Orcaworks includes:

• Memory scoping (per session, user, tenant)
• Prompt-level access filtering
• Output masking + redaction policies

LLMs don’t have intent.

But you’re on the hook for what they say.

Tool Calls and Output Format Matter

Many agents return raw text.

This makes access control nearly impossible.

You can’t filter or redact what you can’t parse.

That’s why agents should prefer structured outputs.

Using:

• JSON schemas for return types
• Explicit tool calls for API actions
• Code blocks for executable steps

Code-based outputs are more reliable to interpret, enforce, and audit.

However, if your agents return executable code:

• You must sandbox execution securely
• You must inspect tool parameters before invocation

Other Threats to Watch For

LLMs may also:

• Memorize or regurgitate training data
• Embed sensitive data in embeddings
• Cascade mistakes across calls

These threats require not just infra hardening.

They require rethinking what counts as sensitive data.

Securing the Stack: What You Need to Get Right

Most traditional security practices still apply.

But LLMs introduce new challenges.

To secure a modern LLM system, you need end-to-end responsibility.

From ingestion to final response.

1. Start with User + Access Modeling

Define your access model before building pipelines.

• Who are your users?
• What groups or tenants do they belong to?
• What data can they access?

Every document should be tagged with access metadata at ingestion.

2. Delegate and Enforce Rights in Agent Execution

User identity must propagate across agent execution.

Without being leaked to the LLM.

Orcaworks enforces policy at every retrieval and tool call.

3. Isolate Execution Environments

Every agent run should be sandboxed.

• Use containers like Docker
• Use ephemeral secure sandboxes
• Scope memory, cache, and logs per user

Isolation is both a security control and a safety net.

4. Log Every LLM Call

Once something leaks in a response, it’s too late.

That’s why Orcaworks logs:

• Every prompt and response
• User, tenant, and workflow context
• Retrieval and tool results

This enables audits and incident response.

Data Privacy in LLM Workflows

Sending sensitive prompts to third-party APIs is risky.

Orcaworks reduces risk with:

• PII redaction before LLM calls
• Local inference support
• Optional PII detection and alerting

We support regulated environments.

LMS Example: Protecting Student Data

Agents retrieve past graded answers using RAG.

This improves grading quality.

But:

• Only same-tenant data should be retrieved
• Retrieved examples reach the LLM
• Leaks are irreversible

Orcaworks ensures:

• Tenant-tagged ingestion
• Permission-scoped vector search
• Pre-LLM access enforcement

This keeps compliance risk low.

Bonus: Guardrails for Sensitive Workflows

Guardrails help when things go wrong.

• Validate intermediate outputs
• Pre-filter content with smaller models
• Add human checkpoints
• Restrict tool usage

You’re constraining creativity just enough to stay safe.

Redaction alone is not a solution.

The real defense is scoping and filtering at the source.