Cross-Module Context Handoff Sanitization Automation: A Screen Can Say Where You Are, Never Who You Are

Handing an assistant a bit of context about the screen someone is already on is a small, obviously useful thing — it means not having to re-explain which invoice or which deal is in focus. But that same channel, if left unguarded, is also the easiest place for a bug or a compromised client to slip in something that decides authority — an organization ID, a role, a permission flag — hoping the assistant on the other end treats a screen's own claim as good enough. An internal AI that reaches across a whole company's modules needs a rule that never lets that shortcut work, not a policy someone has to remember to enforce screen by screen.

A context object that travels between a screen and an internal AI assistant is exactly where two different failure modes meet: it is used often enough that a hand-checked allowlist per field is tedious to keep current, and it is trusted enough that a person building the sending screen might reasonably assume "the receiving side will figure out what it needs." A rule that only checks field names allows content to hide under an unexpected key; a rule that has no size limit allows a full record to travel through a channel meant for a label and an ID; and a rule that silently drops what it doesn't like leaves nobody able to tell, later, whether a missing field was policy or a bug.

Every context object that reaches Axiom carries a protocol version (`centriu.context/1`) and is read through one function, `sanitizarContexto()`, shared byte-for-byte between the module's own app and every Edge Function that accepts context — a generation script keeps the two copies from silently drifting apart, with a `--check` mode specifically built to catch that drift. Three fields refused on principle even if a screen tries to send them: organization, user, and permissions (along with their common aliases — tenant, role, scopes, entitlements) — because authority in Axiom always comes from the caller's own verified identity, never from a claim inside the context payload itself.

What IS allowed is narrow and shaped: which system is handing off (a lowercase slug), which surface it came from (the Axiom screen itself, ChatGPT, or a system-to-system call), an optional area and route within that system, an entity being looked at (a type and an opaque ID Axiom never interprets — it just passes it back to the tool that owns it), a selected date range in ISO format, a currency CODE only (never a monetary value), a short list of filters, and a list of capability hints a screen can offer as a navigation cue — re-verified against the real registry and the caller's own identity before anything is trusted. Every one of those fields has a hard character or item cap, because a context object is meant to be a ticket, not an attachment.

On top of the field allowlist, values themselves are checked for the SHAPE of a credential regardless of which field they arrived in — seven distinct patterns cover JSON Web Tokens, both old- and new-format Supabase keys, OpenAI-style secret keys, GitHub personal-access tokens, Slack tokens, Google API keys, PEM-formatted private keys, and Bearer/Basic authorization headers. A key whose NAME suggests it carries full content — body, payload, an attached document, a transcript, a complaint, a medical or financial extract — is refused outright, not merely trimmed, because summarizing a document is a different operation from receiving one wholesale. Nested objects inside filters or metadata are stripped for the same reason stated directly in the code's own comment: the context is shallow on purpose, because nesting is where a document hides.

None of this fails the whole request over one bad field. A single strange filter gets pruned, with the removal recorded under one of six named reasons — authority claim, looks like a secret, carries full content, text too long, wrong format, or over a numeric limit — and that record travels all the way to Axiom's own audit trail alongside the call it accompanied. The model itself is then told, in a fixed block of plain language, exactly what the surviving context does and does not mean: it says WHERE someone is, it grants NOTHING, and if a downstream tool refuses an action, the honest response is to report the refusal — not to try another path, and not to state a remembered number as if it were current.

A screen hands Axiom context that includes a filter whose value happens to match the shape of a Bearer authorization header — pasted in by mistake during testing, not a real attack. Rather than passing it through because the field name looked innocuous, the sanitizer recognizes the VALUE's shape, strips it, and records the removal under "looks like a secret" — visible later in the audit trail — while the rest of the context (which system, which entity, which period) reaches the model exactly as sent.

A screen can hand Axiom useful, specific context without that channel ever becoming a second, informal way to claim authority or leak a credential. Nothing that gets stripped disappears without a trace — every removal is attributable to a specific, named reason, which matters the day someone asks why a particular filter didn't make it through. And because the sanitizer is generated from one source into every consumer, a fix made once cannot silently fail to reach an Edge Function that was written against an older copy of the rule.

A team that wants to pass an entire document, a full complaint, or a whole conversation transcript through this specific handoff channel will find it refused by design — that is a different operation (fetching a document a person is authorized to see, through the tool that owns it), not a context field. A team expecting the context object itself to grant access to a system will find the opposite: the context describes a screen, and every real read or write still goes through the owning tool's own identity, role and plan checks, independent of anything the context claimed.

Trusting whatever fields a sending screen includes — because it is "internal, so it should be safe" — quietly turns a convenience channel into a second authority path the moment any one screen gets it wrong. Centriu Axiom instead treats every context handoff as untrusted input worth the same discipline as an external one: a fixed allowlist, credential-shape detection independent of field names, hard size caps, and a named reason for every single removal, so the channel can be genuinely useful without ever being able to grant what only a verified identity should grant.