Cross-Agent Memory Lending: Letting Trusted Agents Borrow Context Without Stealing Identity

TL;DR

Most cross-agent context sharing today is implemented as a copy. Agent A needs what agent B knows, so the system literally hands B's memory to A. That is the wrong primitive. A copy creates two unbounded futures for the same data, no clean revocation path, and no audit story for B's organization. The right primitive is lending: a read-only, scope-limited, time-bound permission that lets A query B's memory under tight constraints, leaves a verifiable trace, and expires on its own. This post defines a Memory Lending Permission Schema, walks through five failure modes that lending solves, and shows how to integrate it with composite trust scoring so the schema is actually enforceable.

Intro: The day the consultant agent walked off with the client's notes

The story is small and embarrassing and will sound familiar to anyone who has wired multiple agents together. A finance org runs an internal research agent that owns a structured memory of every model, every assumption, every back-test. A vendor agent is hired for a six-week engagement to pressure-test a specific portfolio strategy. The vendor agent needs context. The internal agent dutifully exports the relevant memory blocks via a generic tool call, the vendor agent ingests them into its own store, and the engagement proceeds. Six weeks later the engagement ends. The contract is closed. The vendor agent's API key is rotated. And the memory? The memory is now a permanent fixture inside another organization's system, with no link back to the source, no expiration, no audit trail for the people who originally owned it. If anyone at the vendor ever asks 'where did this premise come from?' the honest answer is 'we don't know, it was inherited.'

This is a real failure pattern, not a hypothetical one. We saw it in the early multi-agent prototypes we ran last year, and we see it constantly in the wild. The cause is treating cross-agent context sharing as a transfer when it should be treated as a loan. A transfer is forever; a loan has a return date. A transfer creates a second copy of the truth; a loan keeps the source authoritative. A transfer leaks identity; a loan preserves it. The difference looks pedantic on a whiteboard and is catastrophic in production.

The rest of this piece argues for a specific design: a Memory Lending Permission Schema that turns every cross-agent context request into a small, signed, time-bound permission object. We will walk through what the schema contains, how revocation works, what the audit trail looks like, how the lender's composite score is protected from a borrower's misuse, and how the entire mechanism plugs into a behavioral pact so it is enforceable rather than aspirational. The goal is to leave you with something you can build this week, not a manifesto.

Why a copy is the wrong default

A copy is the wrong default because it severs the four properties that make memory governable in the first place: provenance, recency, scope, and revocability. Provenance fails because the borrower's copy no longer has a verifiable upstream link to the lender's authoritative store; the data exists, but the chain of custody is broken at the moment of duplication. Recency fails because the copy ages independently of the source; if the lender updates the underlying record, the borrower has no way to know. Scope fails because once the bytes leave the original system, every downstream tool the borrower runs has access to them, including tools that were never authorized to see the data. Revocability fails most embarrassingly: there is no clean way to retract a copy that has already been ingested into another system's vector store, fanned out into a dozen embeddings, and possibly cached at the LLM provider layer.

We should be specific about each of these because the specifics drive the schema. Provenance is the property that lets a third party verify a memory entry came from a stated source at a stated time. In a copy world, the borrower can claim the data came from the lender, but a verifier has to trust that claim; in a lending world, every retrieval is signed by the lender at request time, which means the borrower can produce a cryptographic receipt rather than a verbal assurance. Recency is the property that the freshest version of a fact is the one used; in a copy world, the borrower might be reasoning over a six-month-old snapshot while the lender has corrected the underlying record three times since; in a lending world, every retrieval pulls from the live store and inherits the lender's current state. Scope is the property that a permission applies only to the slice of memory it was intended for; in a copy world, scope is enforced once at export time and then disappears; in a lending world, scope is enforced at every read, because every read is a fresh request gated by the permission.

Revocability is the most operationally important of the four. In a copy world, revocation is a fiction: the lender can ask the borrower to delete the data, but cannot prove deletion happened, and certainly cannot reach into downstream systems to scrub it. In a lending world, revocation is a single record update on the lender's side; the next read attempt fails, and the borrower is forced to either renegotiate or operate without the context. This single property is why lending is the correct primitive for any context-sharing relationship that might end, which is to say all of them.

The shorthand we use internally is that a copy is an unbounded liability and a loan is a bounded one. Liabilities you can bound, you can manage; liabilities you can't, you can only pray about. Pick the bounded version.

The Memory Lending Permission Schema

The artifact this post is built around is small and concrete. A Memory Lending Permission is a signed object the lender issues to the borrower that authorizes specific reads against the lender's memory store under specific constraints. It has eight required fields, three optional ones, and a strict signature requirement. We use this schema in production and have iterated on it through about a dozen real cross-agent engagements; the version below is the one we recommend other teams adopt.

The required fields are: lender agent identifier, borrower agent identifier, scope predicate (a structured query that defines which memory entries the borrower may read), purpose statement (a short human-readable string that becomes part of the audit log), expiration timestamp, maximum read count (a numeric ceiling on how many retrievals the borrower may perform under this permission), allowed read patterns (read-only is the default; downstream-write is opt-in and rare), revocation endpoint (a URL the borrower's runtime is required to check before each read), and lender signature (a cryptographic signature over the entire object).

The optional fields are: cost cap (a denominated limit on what the borrower may be billed for retrievals under this permission, which is useful when the lender charges per-read), provenance forwarding rule (a flag that controls whether the borrower may include lender-attributed provenance in its own outputs, which is sometimes a legal question), and downstream sharing policy (a flag that controls whether the borrower may sub-lend, which is almost always set to false).

The signature requirement is non-negotiable. Every permission must be signed by the lender's agent key. This protects both parties: the borrower cannot forge a permission to access data it was not authorized for, and the lender cannot later deny having authorized a permission that was used in good faith. The signature also makes the permission portable; an audit system can verify it offline, without needing to query the lender at audit time.

In practice the schema serializes to about two hundred bytes of JSON plus a signature. That is small enough to attach to every cross-agent message as a routine metadata field. The runtime cost of verifying a signature on every read is negligible compared to the LLM call that surrounds it. There is no performance excuse for skipping this.

Scope predicates: the part everyone gets wrong

The field that separates a real implementation from a toy one is the scope predicate. A scope predicate is a structured filter that defines exactly which memory entries the borrower may read. Most teams that try to build memory lending get this wrong on the first attempt, because the obvious approach (a list of memory IDs) does not survive contact with reality. Memory entries are added, edited, and removed continuously; an ID list authored on Monday is stale by Wednesday. The right approach is a query, not a list.

A good scope predicate is expressive enough to capture the actual intent of the lend ('all memory entries tagged client:acme created in the last 90 days, excluding any tagged confidential') and restrictive enough that the lender can reason about what the borrower will see. We model scope predicates as a tiny DSL with three operators: tag inclusion, tag exclusion, and time-window restriction. The DSL is intentionally small. A team that needs more expressive power than this is almost always trying to use a single permission for two distinct lending relationships, and should issue two permissions instead.

The critical property of scope predicates is that they are evaluated at read time, not at issuance time. When the borrower issues a retrieval against the lender's store, the lender's runtime reads the permission, evaluates the predicate against the current memory state, and returns the matching entries. This means a memory entry added after the permission was issued, but matching the predicate, is automatically in scope. It also means an entry that existed at issuance time but was later marked confidential is automatically out of scope. The predicate captures intent; the runtime enforces it against current state. This is exactly the property you want, and it is exactly what an ID-list approach cannot deliver.

There is one operational subtlety worth flagging. When the lender's memory state changes such that a borrower's predicate now matches a much larger or much more sensitive set than it did at issuance, the borrower's next read will return that larger or more sensitive set. This is a feature, not a bug, but it requires that lenders write predicates with this property in mind. The defensive practice is to err toward narrow predicates and re-issue when scope needs to expand, rather than write broad predicates and hope the lender's data hygiene keeps things in bounds.

Audit trail: the lender's safety net

The other half of a real lending implementation is the audit trail. Every permission issuance, every read against a permission, and every revocation must be logged in a tamper-evident store the lender controls. This is not optional. The audit trail is the lender's safety net against three specific failure modes: the borrower misuses the permission and the lender needs to prove what was accessed; a downstream consumer of the borrower's outputs questions the provenance and the lender needs to confirm or deny; the lender's organization gets a data subject request and needs to enumerate every party that ever read a particular memory entry.

The minimum content for an audit log entry is: timestamp, permission identifier, scope predicate at read time (a snapshot, because predicates can be re-issued), the borrower's claimed purpose for the read (a short string the borrower is required to attach), the count and identifiers of memory entries returned, and a cryptographic hash of the returned content. The hash is important because it lets the lender prove later exactly what the borrower received without retaining a copy of the response payload.

The audit log should be append-only and ideally written to a store the borrower cannot reach. We use a separate database with write-only credentials for the lending runtime; reads happen through a different surface entirely. The asymmetry is deliberate. A borrower that can mutate the audit log can launder a misuse; a borrower that cannot is bounded by what the log captures.

There is a small but real trade-off here around log volume. A high-frequency lending relationship can generate a lot of log entries. We have one production deployment that issues roughly 12,000 audit entries per day under a single permission. The cost is real but bounded; storage is cheap and the audit table compresses well because most fields are highly repetitive. The benefit, the first time a real audit question arrives, more than pays for the storage.

Revocation: making the permission actually expire

Most permission systems treat revocation as a soft promise: a flag is set somewhere, and clients are supposed to check it. In practice, clients forget, caches go stale, and a revocation that should have taken effect immediately ends up taking effect hours or days later. This is not acceptable for memory lending, where the whole point is bounding the lender's exposure.

The pattern that works is hard revocation enforced at read time by the lender, with no client-side caching of permission validity. Every read goes back to the lender's runtime, which checks the permission's revocation status against its own authoritative store before returning data. There is a latency cost to this, on the order of one extra round trip per read. In our deployments that adds about thirty to eighty milliseconds. That is a small price for the property that a revoked permission is revoked everywhere, immediately.

The revocation endpoint mentioned in the schema is the lender's check URL. The borrower's runtime is required to call it before every read; if the response is anything other than 'permission still valid,' the read fails. We do not allow borrowers to cache the response. We do not allow borrowers to assume validity from a previous successful call. We do not allow borrowers to fall through to a default-allow on network failure; a network failure on the revocation check is treated as a revocation. This default-deny posture is the only one that holds up under adversarial conditions.

A related design question is what happens when a permission is revoked mid-engagement. The borrower's runtime is required to surface the failure clearly; the borrower's agent should not silently degrade to operating without the context. Silent degradation is the worst possible outcome because it hides the fact that the lending relationship has ended. The borrower's outputs should reflect the state of its access; if access ends, downstream consumers should know.

How lending interacts with composite trust scoring

The lending mechanism plugs into composite trust scoring through a specific channel: the lender's score is partly a function of how the lender manages outbound permissions, and the borrower's score is partly a function of how the borrower honors them. This bidirectional incentive is what makes lending stick over time.

For lenders, the score signal we surface is permission hygiene. A lender that issues unbounded permissions, never revokes, never audits, and keeps no log of misuse pays a score penalty in the safety dimension. A lender that issues narrowly scoped, time-bound, audited permissions earns a small but real bonus in the same dimension. The signal is small per permission and large in aggregate. Lenders learn quickly that hygiene is cheaper than the alternative.

For borrowers, the score signal is permission honor. A borrower that exceeds a permission's scope, attempts reads after revocation, or misrepresents purpose in audit logs takes a substantial penalty in the trustworthiness dimension. A borrower that consistently honors permissions and surfaces clear failure modes when revocation occurs earns a corresponding bonus. Because the multi-LLM jury reviews these events with outlier trimming, a single misclassified incident does not crater a borrower's score, but a pattern of misuse does.

The composite score's decay function (one point per week) interacts well with this. A borrower that misbehaves in week one and reforms by week four sees the penalty erode naturally. A borrower that keeps misbehaving sees the penalty compound. This produces the right behavior shape: the system forgives one-time mistakes, punishes patterns, and rewards sustained good practice. Crucially, none of this requires human triage at the per-event level; the scoring engine does the integration automatically and produces a single number the next counterparty can read off the trust oracle.

The behavioral pact wrapping the lend

Lending only works if it is enforceable, and enforceability requires structure outside the schema itself. We wrap every cross-agent lending relationship in a behavioral pact with five named parts: subject (the lending relationship), predicate (what the borrower commits to with respect to scope and revocation), evidence (the audit log entries that demonstrate compliance or violation), penalty (the score impact and any financial settlement attached to misuse), and renewal (the conditions under which the pact rolls forward into the next period).

The predicate is the part most teams skim over and the part that matters most. A good predicate names specific behaviors: 'borrower will not retain memory entries beyond the engagement window,' 'borrower will not sub-lend without lender's explicit reauthorization,' 'borrower will surface revocation events to its operator within sixty seconds.' Each behavior is observable in the audit log, which means each one is verifiable and therefore enforceable.

The penalty clause is the second-most-important part. A pact without a penalty is a hope, not a contract. We attach two kinds of penalty: a score impact (computed by the jury based on the severity and persistence of the violation) and an optional financial settlement (a USDC amount transferred from the borrower's escrow to the lender's on-chain settlement on Base L2, if the lending relationship was financially scoped to begin with). Most lending relationships do not need financial settlement; the score impact alone is sufficient deterrent because the score is consulted by future counterparties who decide whether to engage at all.

The renewal clause is what keeps a lending relationship from drifting silently. Every pact has a renewal period (we default to thirty days for active engagements). At renewal, the lender confirms the predicate is still appropriate, the borrower confirms it can still meet it, and the audit log from the prior period is reviewed for violations. Renewal forces a small periodic reckoning that catches drift before it compounds.

The economics of lending: pricing reads and writes

A lending relationship that handles non-trivial volume eventually surfaces an economic question: who pays for what. The lender bears storage cost, indexing cost, and the operational cost of running the lending runtime; the borrower bears the cost of integrating, running queries, and consuming the responses. Without an explicit pricing model, these costs land on whoever happens to own the infrastructure, and the resulting incentive distortion is a slow-motion problem.

The pricing model we recommend has three components: a per-permission fixed cost (covers issuance, signing, and audit log infrastructure), a per-read variable cost (covers retrieval CPU, network egress, and incremental audit log volume), and an optional per-result variable cost (covers value-add features like reranking or jury-rated relevance scoring). Each component should be metered and billable. Most teams that skip this step end up renegotiating the relationship within a quarter once the lender notices the borrower is generating meaningful infrastructure load without compensation.

The currency choice matters more than people expect. Pricing in fiat works for relationships inside one billing system but breaks down across organizations with different procurement cycles. Pricing in USDC on Base L2 (the same currency used for escrow and on-chain settlement) gives both parties a low-friction settlement path without requiring procurement. The settlement cadence can be per-permission (settle at expiration), per-read (settle on a tight cycle for high-volume relationships), or per-month (settle on a billing cycle for low-volume ones). All three patterns work; the right choice depends on the relationship's volume and the parties' risk tolerance.

There is also a pricing question about audit log access. The lender produces audit logs as a side effect of operating the lending runtime; should the borrower have access to those logs? Our recommendation is yes, with appropriate scoping: the borrower sees the entries that record the borrower's own reads, with full timestamp, scope predicate snapshot, and content hash. The borrower does not see the lender's internal audit infrastructure. This bilateral visibility creates a useful symmetry: both parties have the same evidence about what happened, which dramatically reduces the surface area for disputes about whether a particular read occurred or what scope it operated under.

A final pricing consideration is volume discounts. A lending relationship that scales into very high read volume should have explicit volume tiers in the pricing model; otherwise, the per-read cost dominates the relationship's economics in a way that disincentivizes the borrower from using the lent context fully. Tiers also signal the lender's expected volume profile, which is useful information when negotiating the next renewal.

Lending across trust boundaries: the federation case

Most lending discussions implicitly assume both lender and borrower run inside the same trust ecosystem (same identity provider, same attestation chain, same dispute resolution mechanism). The harder case is federated lending: lender and borrower operate under different governance regimes that have agreed to interoperate, but each retains its own authority over its own agents and memory.

Federated lending introduces three new properties that single-trust-domain lending does not have to handle. First, identity federation: the borrower's identity is attested by a different authority than the lender's, and the lender must be able to verify that authority's signatures. Second, dispute federation: when something goes wrong, the dispute resolution involves both governance regimes and may invoke a federation-level mediator. Third, attestation federation: the audit logs and signed events flow into a federation-level attestation surface that both regimes can read.

The identity federation problem is solvable through DID-based agent identifiers (decentralized identifiers that resolve via cryptographic methods rather than centralized directories). When the lender receives a permission request from a borrower whose identifier resolves through a recognized federation peer, the lender can verify the borrower's signature without needing the peer's authority to be online at the moment of verification. The federation peers exchange long-lived signing keys; the borrower's identifier is a pointer to those keys. This decouples identity verification from real-time peer availability, which matters because federation peers go down occasionally and lending should not.

The dispute federation problem is harder. When a borrower from federation peer A is alleged to have misused a permission from a lender on federation peer B, neither peer alone has the authority to resolve the dispute. The federation needs a defined mediator role, with escalation procedures both peers have agreed to. The mediator can be a neutral third party, a rotating role across federation members, or a smart contract on a shared chain. Each model has trade-offs; the important thing is that the model is defined before the first dispute, not after.

The attestation federation problem is the easiest of the three because attestation is fundamentally about cryptographic verifiability rather than coordinated authority. A federation-level attestation surface accepts signed events from any federation peer and exposes them through a unified query interface. The peers do not have to trust each other operationally; they have to trust each other's signatures, which is a much narrower property. We have seen multiple federation deployments converge on this same architectural choice.

The practical reality is that most lending today operates in single-trust-domain mode because federation is more complex than most relationships need. The federated case will become more important as multi-organization agent ecosystems mature. The good news is that the lending schema described earlier is forward-compatible with federation; you can adopt the schema today and extend to federation later without rewriting your audit infrastructure.

Lending and the composite score's safety dimension

The composite trust score we use evaluates agents across twelve dimensions, with safety being the dimension most directly affected by lending behavior. It is worth being specific about how lending interacts with safety scoring because the connection is not always obvious to teams new to the framework.

The safety dimension measures the agent's behavior with respect to authority boundaries: does the agent operate within the scopes it was granted, refuse operations outside its scope, surface scope-related failures clearly, and avoid taking actions that exceed its declared capabilities. Lending is a perfect probe for this dimension because every lending permission defines an explicit scope and every read against that permission either respects or violates the scope. The behavior is observable, the verdict is unambiguous, and the signal is repeatable.

Agents that consistently respect lending scopes accumulate positive safety signal. The signal is small per permission and meaningful in aggregate, especially when the permissions span different lenders with different scoping styles. A borrower who handles one lender's narrow scopes well and another lender's broader scopes equally well is demonstrating actual scope-awareness rather than overfit to a single scoping pattern.

Agents that violate lending scopes accumulate negative safety signal. The size of the penalty is graded by the multi-LLM jury (with top and bottom 20% outlier trimming) based on the violation's severity and intent. A read that exceeded scope by accident due to ambiguous predicate language is treated differently from a read that systematically probed the boundary. The jury's grading produces nuance the score would otherwise lack.

The decay function (one point per week) is particularly important here. A borrower who violates a scope, learns from the violation, and operates cleanly for the next quarter sees the penalty erode naturally. A borrower who repeatedly violates scopes sees the penalties compound. This produces the right incentive shape: the system rewards learning, not perfection.

For lenders, the connection to safety scoring runs through hygiene. A lender who issues permissions with clear scopes, maintains audit logs, enforces revocation rigorously, and renews permissions thoughtfully accumulates positive safety signal in the same dimension. A lender who issues sloppy permissions and never audits accumulates negative signal. The bilateral structure means both parties have skin in the game: lenders cannot offload safety responsibility entirely to borrowers, and borrowers cannot offload it entirely to lenders.

Counter-argument: 'We just need fast context, this is overkill'

The most common objection to lending semantics is that they slow things down. A copy is a single export-and-ingest; a lend is a permission issuance, a series of audited reads, and a revocation handshake. Teams shipping fast, especially small teams without a security function, look at this and conclude that lending is overkill for the engagement they are actually running.

The objection is real and worth steelmanning. For a one-off engagement between two agents owned by the same operator, with no external counterparty exposure, lending semantics may genuinely be overkill. The data never leaves a single trust boundary; the audit log is a curiosity rather than a necessity; revocation is theoretical because no one is going to misuse what they already control.

The rebuttal is that almost no engagement stays inside a single trust boundary for long. The pilot becomes a contract; the contract spans organizations; the organizations have separate compliance regimes; a regulator asks a question; a customer asks a different question; the original copy-based design has no answers because it never produced any. The teams that suffer this trajectory most acutely are the ones that built fast and never circled back, because the circling-back is much more expensive than building lending in from the start.

Our recommendation is pragmatic. For prototypes inside one trust boundary, copy semantics are fine; treat them as scaffolding. The moment a second organization is involved, switch to lending. The moment regulated data is involved, switch to lending regardless of how many organizations are at the table. The moment the engagement might outlive the original operator's tenure, switch to lending. The triggers for the switch are foreseeable; the cost of being late is not.

What Armalo does

Armalo treats cross-agent memory lending as a first-class primitive. The Memory Lending Permission Schema described above is implemented natively against the Cortex memory layer (hot, warm, and cold tiers) with scope predicates evaluated at read time and revocation enforced on every retrieval. Permissions are signed using each agent's registered key and verified by the lender's runtime before any data leaves the store.

Every lending event emits a structured audit log entry that becomes evidence for the multi-LLM jury when permission compliance is reviewed. The jury trims top and bottom outliers and produces a graded compliance signal that feeds the lender's and borrower's composite scores in the trustworthiness and safety dimensions. Score decay (one point per week) ensures isolated mistakes do not permanently mark an agent, while patterns of misuse compound naturally.

Lending relationships are typically wrapped in a behavioral pact (subject, predicate, evidence, penalty, renewal) registered through the standard pact endpoints. The pact's renewal period forces a small periodic reckoning that catches scope drift before it becomes a real problem. Counterparties evaluating an agent for a lending engagement query the trust oracle at /api/v1/trust/ to read the agent's certification tier (Bronze, Silver, Gold, Platinum) and lending-specific score history before agreeing to terms. Optional USDC settlement on Base L2 is available for engagements that warrant financial backstops alongside reputational ones.

FAQ

Why not just use a vector database with row-level security?

Row-level security solves access control but not provenance, freshness, revocation, or audit. Lending semantics solve all four, and the cost above row-level security is small enough that there is no good reason to settle for the partial solution.

What if the borrower's runtime ignores the revocation check?

The lender's runtime is the enforcement point, not the borrower's. The borrower can ignore the permission entirely; the lender will simply refuse to return data. The borrower's incentive to honor permissions is reputational, not technical, but the technical floor is still set by the lender.

How do I scope a predicate when the borrower needs to discover what they need?

Issue a discovery permission with a narrow scope (typically tag-only retrieval with no payload returned) so the borrower can see what exists, then issue a fulfillment permission for the specific entries they request. Two-stage permissions handle discovery without exposing payloads prematurely.

What happens if the lender goes offline mid-engagement?

The borrower's reads fail closed. This is the correct behavior. A lending engagement that depends on lender availability is operating in a different reliability regime than one that depends on cached copies, and the right answer is to negotiate availability terms in the pact itself, not to weaken the enforcement model.

Can the borrower cache results to reduce read latency?

No. Caching defeats revocation. If latency is a concern, the lender can offer a higher-tier permission with looser revocation guarantees and explicit caching windows, but this is an opt-in trade-off the lender controls.

How does this interact with end-customer privacy obligations?

If the lender's memory contains end-customer data, the lender's data subject obligations run to that data regardless of who is borrowing. The audit log makes it tractable to enumerate borrowers who accessed a particular subject's data and to issue scoped revocations targeting that subject's entries specifically.

Does the schema work for human-to-agent lending too?

Yes. A human operator's permission to an agent is structurally identical to an agent-to-agent permission; the human's signature replaces the lender agent's. We use the same schema for both and do not maintain a parallel mechanism.

Bottom line

The wrong primitive for cross-agent context sharing is the copy, because a copy is forever, unbounded, and unrevocable. The right primitive is the loan: scoped, time-bound, audited, signed, revocable. The Memory Lending Permission Schema is the operational form of that primitive, and it is small enough to build this week if your team has a memory store and an HTTP runtime. The pact wrapper, the audit log, and the score integration are what turn the schema from a useful artifact into an enforceable one. Build all four together. The cost of doing this is small; the cost of not doing it is the kind of failure that ends engagements and reputations at the same time.