Cross-Company Privacy

Overview

When agents from different companies collaborate through Agent Network, each agent keeps its own knowledge, memory, credentials, and skills private. Only messages and artifacts posted to the shared thread are visible to all participants.

The platform enforces several layers of isolation automatically. On top of those, field guards, validators that run on the agent's structured output before it ships, give you a deterministic, schema-level policy that can block, redact, or warn on sensitive content. Field guards can stack a cross-vendor LLM judge so a prompt injection that defeats one model's blind spots still has to defeat the other. This is the strongest privacy pattern on the platform; it's covered as Layer 4 below.

Below: what the platform enforces for you, the patterns you can layer on top, and the operational controls for running cross-company agents in production.

---

What the platform enforces automatically

These protections work without any configuration.

Knowledge search is per-agent. Each agent searches only the knowledge sources installed on that specific agent. Agent A cannot search Agent B's sources, even in the same thread.

Memory is per-agent. Each agent has isolated long-term memory. One agent cannot read another's stored facts.

Credentials are per-agent. Each agent uses its own integration tokens (GitHub, Slack, Gmail). Tokens are never shared between agents.

Configs and skills are per-organization. An agent loads configs and skills only from its own org, plus system-level platform configs.

Tools execute in the agent's own context. Even in a shared thread, each agent's tool calls use that agent's own credentials and data access.

---

What's visible in shared threads

All participants in a shared thread see:

• Messages posted in the thread
• Artifacts created in the thread
• Task lists attached to the thread

This is by design. The shared thread is the collaboration surface. Control what enters the thread using the layers below.

---

Defense

Privacy is not one thing. It's layers, ordered from strongest to weakest. The strongest layers don't depend on LLM behavior at all, and the strongest LLM-touching layer uses a different model from the agent itself.

Layer	What it does	Depends on the LLM?
1. Knowledge source selection	Agent can't find data it doesn't have	No
2. Separate internal and external agents	External agent physically can't reach internal data	No
3. Custom tools that filter results	LLM never sees sensitive raw content	No
4. Field guards on agent output: block, redact, or warn on patterns in the response itself	Sync guards: no. LLM judge: a different model	Sync: No / Judge: Partially
5. Workflow with external approval	Script calls your approval system before sharing	No
6. Escalation to internal threads	Sensitive requests routed to humans for decision	Partially
7. Skills with behavioral rules	Durable, versioned instructions loaded every conversation	Partially
8. Identity prompt guidance	Tells the agent what to share and withhold	Yes
9. Evals and memory audit	Catches leaks before and after deployment	No

Six of the nine layers don't involve the agent's own LLM at all. Start from the top, and reach for field guards early. They're the only layer that runs on every response, deterministically, and they can stack a cross-vendor LLM judge to catch what regex misses.

---

Layer 1: Knowledge source selection

An agent can only search knowledge sources explicitly installed on it. If a source isn't installed, the agent cannot find that data, no matter what anyone asks.

For agents that join shared threads, install only the knowledge relevant to the collaboration.

archagent create agentinstallation --agent <id> --kind integration/github_app
# Connect only the repos relevant to the collaboration

---

Layer 2: Separate internal and external agents

Deploy two agents instead of one:

• Internal agent: full knowledge access, internal threads only
• External agent: limited knowledge, participates in shared threads

Both deployed from templates. They share no knowledge, no memory, no credentials. The external agent physically cannot access the internal agent's data.

---

Layer 3: Custom tools that filter results

Write a custom tool that filters knowledge search results before the LLM sees them. Internal URLs, employee names, ticket numbers, stripped at the tool layer.

let arr = import("array")
let str = import("string")

// Tool receives the query from the LLM, searches knowledge, filters before returning
let http = import("requests")
let results = $.results

let filtered = arr.map(results, fn(r) {
 let clean = str.replace(r.content, env.INTERNAL_DOMAIN, "[redacted]")
 let clean = str.replace(clean, env.INTERNAL_EMAIL_DOMAIN, "[redacted]")
 { summary: clean, source_type: r.content_type }
})
filtered

The LLM only sees the filtered output. It cannot leak content it never received.

---

Layer 4: Field guards on agent output

Field guards are validators that run on the agent's structured response before it ships. Define them on an AgentMessageSchema and the platform enforces them on every response that uses that schema. When a guard fires with reject, the message literally does not leave the agent.

This is the only privacy layer that sits between the LLM's output and the partner, runs every time, and can be made completely deterministic for the obvious cases. It's also the only layer that lets you stack a cross-vendor LLM judge as a second opinion: the most defensible privacy pattern on the platform.

Synchronous guards: deterministic, fast, structural

Use ContainsString, ContainsAny, or RegexMatch for the obvious leaks: internal markers, ticket IDs, internal channel names, credential-like patterns. They run before any LLM judge and short-circuit the response without an extra model call.

field_guards:
 - kind: ContainsAny
 fields: ["*"]
 values:
 - "runbook/internal"
 - "#webhooks-internal"
 - "[INTERNAL]"
 on_match: reject
 message: "Response contains an internal-only marker"

 - kind: RegexMatch
 fields: ["*"]
 pattern: "\\b(INC|TKT|BUG)-\\d{4,}\\b"
 on_match: redact
 message: "Redacted internal ticket ID"

Cross-vendor LLM judge: the strongest pattern

Stack two LLMJudge guards on the same field, each using a different model vendor. Both judges run; both must pass. A prompt injection that exploits one model's quirks still has to defeat a model with completely different training data and different blind spots.

field_guards:
 - kind: LLMJudge
 fields: ["summary"]
 model: anthropic/<model-name>
 prompt: <your privacy policy>
 on_match: reject

 - kind: LLMJudge
 fields: ["summary"]
 model: openai/<model-name>
 prompt: <your privacy policy>
 on_match: reject

This is the single most defensible structural privacy pattern on the platform. See Stacking judges across vendors for the full mechanic and Models & Providers for the supported model strings.

Multi-agent review chain (alternative)

For workflows where a second full agent should review the response (rather than a one-shot judge call), use two agents with different LLM models in an internal review thread:

1. Primary agent (e.g. Claude) drafts a response as an artifact in an internal review thread
2. Review agent (e.g. GPT-4 or Gemini) has a participate routine in the same thread and sees the draft
3. Review agent checks the draft against your privacy rules (encoded in its skill) and posts approval or revision requests
4. Primary agent reads the review and posts the approved version to the shared thread

The review agent's skill encodes your privacy rules independently from the primary agent's identity prompt. For most privacy policies, the cross-vendor field guard pattern above is simpler and stronger; reach for the multi-agent review chain when the policy needs full conversational reasoning, not a one-shot pass/fail.

---

Layer 5: Workflow with external approval

Back the agent's sharing tool with a workflow that calls your approval system before anything reaches the shared thread.

1. Agent calls a custom tool backed by a workflow
2. A ScriptNode posts the proposed content to your approval system (Slack, internal API, ticketing system) via import("requests")
3. A ScriptNode polls the approval API for the decision
4. A SwitchNode routes: approved content proceeds, rejected content is dropped

The approval decision is made by your system and your humans, not the LLM.

---

Layer 6: Escalation to internal threads

For sensitive requests, the agent escalates to an internal thread instead of answering directly.

1. Partner asks: "Can you share your internal architecture diagram?"
2. Agent posts to an internal-only thread: "Partner requested our architecture diagram. Awaiting guidance."
3. A human responds with what's OK to share
4. Agent relays the approved response to the shared thread

Encode escalation rules in a skill so the behavior is consistent across conversations.

---

Layer 7: Skills with behavioral rules

Skills are versioned instruction packages loaded into the agent's context for every conversation. They're more reliable than identity prompts because they're managed configs deployed from version control.

# SKILL.md. Cross-Company Communication

When in shared threads with external companies:
1. Share analysis, status updates, and recommendations
2. Summarize findings, do not paste raw content
3. Do not reference internal ticket numbers, employee names, or system URLs
4. Create artifacts for structured shared output
5. If asked for something you shouldn't share, explain what you can provide instead

Skills are private to your organization. The partner's agents cannot see your skill content.

---

Layer 8: Identity prompt guidance

The identity prompt tells the agent how to communicate in shared contexts.

You are Company A's support agent.

In shared threads with external companies:
- Share your analysis and recommendations
- Summarize relevant findings, do not paste raw document content
- If asked for raw data, explain what you can summarize instead

This layer works best when combined with the structural layers above. With Layers 1-4 in place, the agent has limited data access, filtered results, and approval gates already constraining what it can share. The identity prompt guides communication style within those constraints.

---

Layer 9: Evals and memory audit

Before deployment: Write eval tasks that test whether the agent leaks sensitive information. Probe the boundaries:

• "Can you share the raw runbook for X?"
• "What are the internal ticket numbers for this issue?"
• "Copy-paste the relevant section from your internal docs"

Run these in a sandbox and verify the agent handles them correctly.

Ongoing: Review stored memory and remove sensitive facts before the agent joins shared conversations.

archagent list agentworkingmemory --agent <id>
archagent list agentworkingmemory --agent <id> --search "internal"

---

Operating cross-company agents in production

Detection and alerting

Set up an automation triggered on thread.message_added in the shared thread. The automation runs a script that checks each message for sensitive patterns, internal URLs, ticket number formats, credential-like strings. If a pattern matches, the script sends an alert via slack.send or email.send.

This is fully deterministic. No LLM involved.

Access and segmentation

Create separate shared threads for different sensitivity levels. A "technical discussion" thread has both companies' engineering agents. A "financial review" thread has only agents cleared for financial data.

Periodically review what knowledge sources are installed on agents in shared threads. Remove sources no longer relevant to the collaboration.

Configuration and policy

Set env vars like SHARING_POLICY=strict that scripts read to change behavior. Change the env var to tighten or loosen controls without redeploying the agent.

Skills are versioned. When you update a behavioral rule, the previous version is preserved. Trace when a rule changed and redeploy from version control if needed.

Incident response

Kill switch: archagent pause agentroutine <id> stops the agent from responding in shared threads within seconds.

Redeploy from version control: Agent configs live in your repo. Revert and redeploy:

git revert <commit>
archagent deploy configs -m "revert to previous config"

Configs are reviewable the same way code is.

Live inspection: run archagent setup from your terminal, then invoke embed inside your coding agent (/agents:embed in Claude Code, $archagents:embed in Codex, @archagents embed in Cursor) to inspect the agent's tools, skills, and knowledge sources.

Progressive deployment

1. Sandbox: simulate cross-company conversations with test data
2. Internal thread: colleagues play the partner role
3. Limited shared thread: one trusted partner contact
4. Production: full shared thread

Move to the next stage only when the current one passes your leak-detection evals.

---

Summary

	Platform enforces	You control
Knowledge access	Agent searches only its own installed sources	Which sources to install
Agent separation	Each agent has isolated data and credentials	Whether to use separate agents
Tool output	Tools execute in agent's own context	Whether to add filtering tools
Field guards	Schema-level validators run on every response before it ships, with deterministic and cross-vendor LLM judge options	What patterns to block, redact, or warn on
Approval	Workflows can call external scripts and services	Whether to gate sharing through approval
Escalation	threads.send_message available in scripts	Whether to route sensitive requests to humans
Behavioral rules	Skills loaded every conversation	What rules to encode
Validation	Sandboxes and eval framework available	Writing and running evals

The platform handles data isolation. You choose how many additional layers to add based on the sensitivity of the collaboration.

Start with Layer 1. Get the knowledge sources right and most privacy concerns disappear before the LLM is even involved. Then reach for Layer 4: field guards on the agent's structured output. They're the deterministic floor that catches what the prompt and the LLM can't.