← AICEP home

AICEP 0.1 — Public Draft (RFC)

AI Context Exchange Protocol · Request for Comments. We'd love to hear from anyone interested in helping develop this protocol or contributing to it. Contact hello@aicep.ai.

Document purpose: A plain-language description of the AI Context Exchange Protocol (AICEP) version 0.1 public draft, published for comment (RFC).

Status: Public Draft (RFC), open for comments and contributions.

1. Purpose

AICEP is a communication and seating protocol for AI agents. It tells agents—and the people who run them—how to:

• Give each agent a clear identity and standing instructions before it acts.

• Classify content (what it is, how sensitive it is).

• Place agents on a controlled bus (a message path) with rails that keep transfers on policy.

• Perform a controlled crossing—the protocol’s verb: the handoff of typed content from one agent or platform to another.

• Apply Data Loss Prevention (DLP) so proprietary content, personal data, and user-uploaded material do not leak, train external models, or land in public / shared places without explicit permission.

2. Audience

This draft is written primarily for individual end users—people who are not necessarily company employees—who want DLP-oriented best practices for their own agent work.

It is especially relevant if you:

• Hold multiple AI subscriptions (coding agents, note-vault agents, multi-agent desktop harnesses, web chat).

• May consolidate work into one platform over time.

• Need content movement managed on purpose, because popular platforms typically do not offer a full dump API for conversations and projects.

Illustrative platform types (categories, not endorsements): coding-agent CLI class; Hermes-class note-vault agents; Claude Desktop / Claude Code class; general-purpose AI assistant / multi-agent desktop harness class; ordinary web chat. When examples name a class, they explain a migration or integration pattern—not a preferred vendor.

Secondary readers: implementers building adapters and validators. They still need the human story first; machine envelopes come after.

Role names used in this document (not personal nicknames):

• Chief of Staff / coordinator agent

• Cyber Security and DLP Agent

• Coding Agent

• Note-vault agent

• Multi-agent desktop harness (host)

3. Definitions (read these first)

Every later section assumes these plain-English meanings.

4. Status of this draft

• Protocol version: 0.1 (Public Draft, RFC).

• Sequence rule: DLP seating first; crossing second.

• Neighbor notes: NVIDIA OpenShell is complementary (runtime sandbox). AICEP differs: it is about identity, classification, seating, and controlled handoffs across tools—not approving endpoints inside a sandbox.

5. What is in scope for 0.1

• Vendor-neutral context exchange between agents and platforms (no shared runtime required).

• DLP-first seating to prevent any kind of sensitive data from being moved, transferred, or published, before any kind of data pub/hand off. Identify and block publication of any kind of sensitive data including:

  • PII
  • PCI
  • HIPAA
  • Intellectual Property in any form
  • Copyrighted Imagery or data

  If an action is set up for publication in any format (file drop, web posting, social posting, commentary, or export), question the user for explicit permission before any data transfer.

• First-crossing types: project.context, decision.record, artifact, task.state.

• `instruction.set` for seating only (standing orders / DLP rules)—it does not ride along inside a project package.

• A practical v1 file bus layout and equivalent paths on MCP/API/broker buses.

• Labels on every object: information types, classification, provenance, subject binding.

Open question kept: How should a user migrate or loosely integrate platforms when there is no full conversation/project dump API? See §16.

6. Control — what humans decide, what agents enforce

Why control exists

Without explicit control, agents will cheerfully paste proprietary text into feedback forms, public issues, shared drives, or the wrong teammate agent. AICEP expects more permission prompts and lockdown than an unconstrained assistant. That is intentional.

What humans control

Humans own the DLP policy and intent:

• What counts as confidential / proprietary in your environment.

• Which tools may hold which types of content.

• Which actions need a yes/no prompt (publish, share, push, send outward).

• Default destinations for saves and pushes: private, user-only, not public, not shared folders, unless you explicitly allow otherwise.

• When to raise or lower a control mode on a connector.

What the Chief of Staff / coordinator does

• Points agents at this protocol on first use.

• Assigns roles and privacy profiles.

• Routes metadata and seating checklists.

• Does not inherit every payload as a “union clearance.”

What the Cyber Security and DLP Agent does

• Watches for accidental proprietary publication.

• Enforces refuse rules (bad ingest, bad share, content egress).

• Stops on violation, reports what almost left, and does not “quietly retry” the same leak with different wording.

Control modes (your decision power)

Default until you seat otherwise: new connectors, CLI, browser copy/paste, and public publish stay in-loop.

Binding surfaces to control modes

Binding means: for each way content can enter or leave (each connection surface), you choose helm / on-loop / in-loop.

7. Data Loss Prevention (DLP)

Industry sense (non-proprietary)

Data Loss Prevention is the practice of identifying sensitive data and stopping it from leaving allowed places. Standard views of where data lives:

• Data at rest — stored on disk, vault, repo, drive, note store.

• Data in motion — moving across a bus, API, upload, or paste.

• Data in use — open in an endpoint session, agent context window, or editor.

AICEP applies all three: label what you store; gate what you move; constrain what agents may use in-session.

How AICEP treats content

• Categorize / classify before publish or forward. If you cannot classify, do not send.

• Default: all user work product is confidential / proprietary.

• No PII leak.

• No IP created under the subscription owner’s work leaves without permission.

• No user-uploaded content leaves the designated secure environment without permission.

• No training use of that content by external AI outside your designated environment.

• Repos and drives shared with agents default to user-only, private, not public, not shared folders unless you explicitly permit otherwise.

Content egress rule-set (folded under DLP)

Treat these as required policy, not optional tips:

• Prefer the term content egress (any outbound content path), not only “vendor egress.”

• Do not put project names, repo paths, protocol payloads, credentials, or personal identifiers into product-feedback forms, public posts, or support tickets.

• Feature requests to a vendor stay generic.

• Description / title panes and demo UI fields are egress surfaces—keep them sanitary.

• A violation is a stop, not an “oops.” Report, do not compound, do not silently resend.

• Optional external sharing marks (e.g. TLP) never loosen a proprietary deny.

Required DLP policy instructions (seating)

Paste standing rules into each agent’s private instructions before first useful work (profile placeholders filled by the coordinator):

• Classify before publish or forward.

• Default deny across roles; no swarm-wide carbon copy.

• Credentials and off-bus marks never ride the bus.

• Content egress rules above are hard stops.

• Connector defaults must be seated before first publish/send/create on that connector.

• Privacy profile, max classification, and allowed types are named explicitly for that role.

8. Agents, identity, and Soul

What an agent is

An agent is software that can pursue goals over time with tools: coding, filing notes, coordinating other agents, scanning for DLP issues, browsing, calling APIs. Use cases include:

• Coding Agent — implement and refactor in a repo.

• Note-vault agent — capture and organize project memory.

• Chief of Staff / coordinator — seat roles, assign profiles, point others at protocol.

• Cyber Security and DLP Agent — refuse leaks and audit near-misses.

• Multi-agent desktop harness — host several roles with shared but gated tooling.

Identity matters because without it, every agent looks like a generic chat with whatever tools are nearby—and will over-share. Identity binds job, allowed types, and refuse rules.

Soul body (`SOUL.md` / `soul.md`)

A soul file is a human-editable markdown document that holds standing identity. Users create a first version at seating and expand it as the agent’s job clarifies.

Belongs in a soul file: role name and mission; boundaries and refuses; preferred tools; DLP profile reference; how to ask the human; tone; non-goals.

Does not belong: live secrets, other agents’ private standing orders, entire chat histories, marketing copy for a vendor.

Sample parameter layout (neutral)

# SOUL.md — \<Role name>

## Identity
- role_name: Cyber Security and DLP Agent
- mission: Prevent accidental publication of proprietary or personal content.
- owner: \<human>

## Boundaries
- may_do: classify; refuse; alert; propose redactions
- must_not: publish; push public; send vendor feedback with proprietary detail

## DLP profile
- profile_id: ip-confidential
- max_classification: Confidential
- types_allowed: [IP, Public]
- content_egress: default deny

## Control binding
- default_mode: in-loop for new connectors; on-loop after refuse-proof

## Collaboration
- reports_to: Chief of Staff / coordinator agent
- may_read_compartments: [ip-confidential]
- may_write_types: [decision.record]

## Growth log
- YYYY-MM-DD: Initial seating from AICEP 0.1.

9. Adapters and connectors

These are first-class ideas—not buried plumbing.

• Connector: the attachment of a platform to a bus (an MCP server binding, an API client, a watched folder, a CLI wrapper). Connectors are seated with defaults before first use.

• Adapter: the translator that maps native artifacts (exports, project files, cards) into AICEP-typed context objects with labels—and maps typed objects back into the destination tool. The adapter labels; the bus enforces. One protocol, many native shapes.

Connectors are how you plug in. Adapters are how native stuff becomes typed. The bus is where typed stuff travels.

10. The bus (and what “wire” means)

Nature of the bus

In AICEP, a bus is the controlled path for context objects. It encodes how you already share information; it should not be looser than your email or document habits. Being able to see a folder is not authorization.

If the word wire appears, it means the message path on a bus—the envelope and route a package takes—not a separate product.

Bus types and what each is for

Roles on the bus

• Adapter — writes typed files / envelopes into the right compartment.

• Subscriber — reads only in-profile compartments; writes only types in its job.

• Archive — redacted sink, not a live mesh.

• Coordinator — seating and routing metadata, not payload vacuum.

Publish / subscribe explained

Publish means a writer places an update where allowed readers can see it (for example a new file under bus/\<compartment>/\<subject>/).

Subscribe means a reader watches that place and ingests new updates according to its profile.

Directionality is not “everyone hears everything.” It is topic/compartment scoped:

• Publishers write into allowed compartments only.

• Subscribers receive only what their privacy profile permits.

• Humans set routines: ingest new file updates; drop or archive superseded ones (amendments are new files that point at prior ids—do not silently edit history).

Reads and writes are the pub/sub methodology on the file bus:

11. Crossing — the verb of the protocol

Crossing is where AICEP happens: the controlled transfer of typed content after seating.

It is not a fancy synonym for installing an app. First crossing answers: seating and identity + DLP policy are in place before the first controlled handoff of typed content. Instantiation alone is not a crossing.

What crosses

A project.context package (plus linked children), not a chat dump and not the destination’s soul.

It carries: stable identity, short current state, links to child objects, provenance, subject binding, classification.

It does not carry: destination standing orders, source soul/memory shards, credentials, off-bus content, out-of-profile types.

Frozen 0.1 type set (human reading)

“Frozen” means: for version 0.1 we agreed this small set is what may travel on the first-crossing path. Other useful things stay in the source tool until promoted.

12. Content format, taxonomy, delivery

Content format is the shape of the payload (prose, chat-shaped body, code, file, page). It is not a substitute for DLP type or classification.

Taxonomy stack (keep distinct):

• Information type — what it is (PII, Financial, IP, Credentials, Public, …).

• Classification tier — how sensitive (Public → Internal → Confidential → Restricted).

• Subject — what it is about (topic tree).

• Format — payload shape.

• Wire/bus type — which 0.1 object type carries it.

Delivery methods: file drop on the bus; MCP/API transfer of the same envelope; human-mediated export when no API exists (still labeled and gated).

13. Access in one place

Access answers: who may receive what, for what job.

Two keys that must not mix:

• Spec access — who may read protocol documents.

• Bus access — who may receive live context objects.

Holding a bus role does not grant the spec. Default deny on the bus: type in job, in-profile, not flattening another job, not off-bus, provenance on, out-of-profile types stripped.

14. Classification (handling)

Tiers: Public → Internal → Confidential → Restricted.

Types include PII, Financial, PHI/medical, IP/proprietary, Credentials (usually off-bus), Public, optional endpoint inventory/posture labels.

Roles receive a privacy profile at seating (allowed types + max tier + handling rules). Cross-profile send needs an explicit bridge and redaction.

14.x Personal devices and vault boundary

Personal-endpoint profile

Handling notes for personal-endpoint:

• Holds endpoint inventory and privacy-posture context for an operator’s personal devices (analysis-first roles).
• Does not receive Financial holdings, PHI, or Credentials by default.
• Does not inherit payloads from finance-pii, cos-admin, or other profiles.
• May receive redacted artifact / project.context children that are in-profile only.
• Device control (MDM enrollment, remote wipe, invasive agents) is outside the profile’s default agency — requires explicit human authorization recorded outside the bus object (decision or task), not implied by holding posture data.

Optional information types (labeling only)

• endpoint_inventory — hardware/software/patch/account-presence inventory derived from local scans or exports. Not Credentials. Often pairs with classification: internal or confidential.
• endpoint_posture — hardening / configuration / risk findings (scores, missing patches, persistence notes). Not Credentials.

Rules:

• If a report embeds secrets (passwords, TOTP seeds, recovery codes, raw key material), those fields are Credentials and must be stripped before bus publish (off-bus / drop).
• Serial numbers, hostnames, and local usernames may be PII or IP depending on org policy; adapters classify conservatively.
• Sharing endpoint reports still follows ACCESS: default deny across roles; no mesh.

Vault boundary

Agent credential vault vs operator personal vault

• Operator personal vault — the human’s own password / identity store. Contents are Credentials / Restricted and off-bus to agents by default.
• Agent credential vault — a separate store (separate account or hard scope) holding only logins the operator has authorized for agent use. Labels and site allowlists may be Internal process objects; secret material remains Credentials / off-bus except via sanctioned injection paths that do not place secrets in model context.
• Shipping personal-vault exports into agent memory, chat, or project.context is an egress / flatten failure.
• Profile personal-endpoint may discuss vault patterns and allowlists; it does not authorize reading the personal vault.

Coordinator seating

When seating an endpoint / privacy agent, assign:

Privacy profile for this role: personal-endpoint
Max classification receivable: Confidential
Types allowed to hold: PII, IP

(Optionally note allowed report types: endpoint_inventory, endpoint_posture.)

15. Content egress (consolidated)

Egress means moving content from one agent tool or environment to another—or to the outside world. Example pattern: Coding Agent → note-vault agent → multi-agent desktop harness.

All egress is evaluated as content egress under DLP (§7). Intra-bus delivery still uses compartments; egress is the door that needs the strongest human intent.

15.x Vault and security-report egress

Agent vault vs personal vault (egress)

1. Personal vault exports (CSV, HTML password reports, TOTP seeds) are Credentials / Restricted. They must not enter vendor sinks, public posts, shared swarm chats, or agent standing memory.
2. Agent vault provisioning and use stay inside the operator’s authorized tooling. Feature requests to vault vendors remain generic (capability language only) — no project names, protocol text, or object payloads.
3. Agents must not paste passwords, OTP secrets, or recovery codes into chat or bus objects. Prefer human-gated or connector injection that keeps secrets off the model transcript.
4. Allowlists (site name, which agent, approval date) may move as Internal process notes; secret fields never do.

Security-tooling reports

1. Endpoint inventory / posture reports shared in-swarm require information_types + classification and an in-profile destination (personal-endpoint or other assigned profile).
2. Reports that would identify proprietary projects, repo paths, or unpublished protocol content must be redacted before any share that leaves the compartment — including “helpful” paste into product-feedback forms.
3. Vendor / marketplace / support channels: default deny for proprietary identifiers. Ask for capabilities (“import CSV from password managers not on the named list”) without naming private protocols or payloads.
4. Sanitary agent Description / Title panes remain egress surfaces: role-only language; no emails, street addresses, account names, or vault locations.

Stop on violation

a vault or report leak is a stop. Tell the human what left and where. Do not resend a “cleaner” proprietary payload to the same sink without an explicit human order.

16. Migration / loose-integration use case (logical)

Goal: Move or loosely integrate work across agent platforms when none offer a full dump API for conversations/projects.

Example classes: Hermes-class note vault → Claude Desktop / Claude Code class; or coding-agent CLI → multi-agent desktop harness / general-purpose AI assistant class; or web chat → any of the above.

Why management is required: there is typically no “share all conversations/projects” API. Content movement is a deliberate export → classify → seat destination → crossing → verify.

Logical steps:

1. Seat DLP and souls on the source and destination (or point the Chief of Staff at this protocol so it applies them).

2. Inventory what must move (project briefs, decisions, artifacts)—not entire chat sludge.

3. Label information types and classification; strip credentials.

4. Use an adapter (even a careful human-written markdown package counts as a temporary adapter).

5. Deliver via the seated bus path (files and/or MCP/API).

6. Destination agent continues without inheriting the source soul.

7. Confirm no public/shared default on repos/drives used for the landing zone.

17. First use

On first use in a new tool (for example a multi-agent desktop harness):

1. Point the Chief of Staff / coordinator agent at the AICEP protocol page (or this pack).

2. The coordinator ingests the protocol.

3. It implements seating—identity, DLP policy instructions, connector defaults—across existing and new agents (or projects, in project-centric tools).

4. Only then allow crossings and routine pub/sub ingest.

18. Conformance (what it means here)

Conformance means an implementation follows 0.1’s type shapes, envelope fields, DLP-first sequence, and refuse behavior closely enough to interoperate.

It is not a certification, accreditation, or compliance mark from any standards body.

19. Cite / disclaimer (short)

Public practices (NIST AI RMF, OWASP LLM risks, FIPS-style confidentiality thinking, optional TLP) are cited as influence. AICEP is in draft form, is not compliant with these public practices and guidance, and stands alone at this time. Collaboration in developing AICEP is welcome; contact hello@aicep.ai.