AI-Compatible RBAC (Alpha)

MCP tool calls carry no backend access identity. When an agent reads a Google Drive document, the response contains the file contents but not who is allowed to see them. When the agent then sends an email, the tool call contains the recipient but nothing linking it back to the source document's access list. Traditional RBAC stops at authentication - it never tracks whether the destination audience is a subset of the source audience.

The problem

An agent connected to Google Drive and Gmail can read a document shared with users A and B, then send its contents to user C. From the identity provider's perspective, no violation occurred - Alice's credentials accessed Alice's files and sent Alice's emails. But the data reached someone outside the original access list.

The root cause: MCP tool calls don't propagate the access control list of the data they return. The agent's session flattens everything into a single context with no memory of who was allowed to see what.

How Edison Watch solves this

Edison Watch extends the Lethal Trifecta with data origin and destination tracking, enforcing that recipients are a strict subset of those who had read access to the source data.

Origin tracking - when an agent reads from a source (Drive, Confluence, OneDrive), Edison records the access list of that resource: who can see this data.

Destination validation - when the agent attempts to send data (email, Slack message, file share), Edison resolves the recipient set and checks: is every recipient in the original access list? If not, the action is blocked.

Subset enforcement - the rule is simple: recipients ⊆ source_readers. If user C is not in the access list of the document the agent read, the send is denied - even though Alice herself has permission to send emails to C.

This goes beyond the standard Lethal Trifecta (which flags broad categories of risk) by making a precise, per-action determination based on the actual identities involved.

---