0:03good afternoon i'm aaron i'm the cto at signal and i wanted to go over a discussion about what we built and we built signal to not know things not your message content not your contacts and with our sealed sender feature not even who's talking to whom meanwhile the defining pitch of the agentic internet is give the agent access to everything and it will do everything and i think those two ideas are on a collision course and i want to talk for bit today about what that collision course looks like so here's kind of the tension in one frame on the left agent value rises with access the more an agent can see and touch your inbox your calendar your code base your production systems the more useful it is that's not a bug in the pitch it is the pitch on the right security rises as knowledge falls at signal we've learned this over a decade every fact your system never receives as well less thing. They can be stolen, leaked, mishandled, or subpoenaed.

0:56You can't lose what you never had. These two curves point in opposite directions, and every team building agents is being pulled along both of these directions, so we've got this massive collision course set up. So let's be honest about what the path of least resistance is, because this is what most agent demos actually show. The easiest way to make an agent useful is to give it everything. Broadcom text makes planning feel intelligent. The agent reads your email threads, your docs, your get history. Suddenly it feels like someone you've worked with for years. Broad authority makes the execution feel magical. It doesn't just draft the email that sends it. It doesn't just find the bug. It opens the PR and merges. And together they create something new, a privileged insider that never sleeps. And you think about what that means.

1:47You've created a service account with the combined access of your most trusted employee operating at machine speed whose every decision is made by a model you can't fully audit that's the demo and it's it is genuinely impressive everyone who's tried it out you know knows how how great these systems are how well they work and how impressive it is what they can do now versus what they could do even only a year ago but it concentrates everything that security engineering has spent 30 years trying to distribute least privilege separation of duties needs know all into one credential one context window one machine it's always a great demo you download this random thing from the internet and immediately grant it root on all your machines

2:31so at signal we came with us from the other direction and knowing less is not a limitation we work around it is the architecture a few examples our servers hold encrypted blobs and minimum route information needed to deliver them we can't read your messages which means we can't hand them to anyone who asked. Still, Cinder goes further. The server doesn't even learn who is messaging whom. Cinder identity is encrypted to the recipient. And the way we built Contact Discovery, your phone needs to know which of your contacts are on signal, but we refuse to learn your address book in order to answer this question. So the lookup happens inside a hardware enclave that even we can't inspect. And we're investigating further cryptographic mechanisms there, like privacy. set intersection, and private information retrieval. But the point isn't these specific mechanisms.

3:20It's that every one of these was a product requirement that looked impossible until we treated ignorance as an architectural property instead of a missing feature. Useful systems do not have to become permanent observers.

3:35Now here's the thing most agent architectures miss. When an agent does a task, it doesn't just produce an outcome. It creates a second data stream about the task. Metadata at machine scale. Let me walk through the five stages on screen. First, retrieve. To do anything useful, the agent pulls messages, documents, repos, records, and history into its context window. That retrieval itself is an access event. Who asked for what, when, and what came back. Second, infer. Intermediate context links, facts that were previously separate. The agent's scratchpad now contains connections between your data where none existed previously. It synthesized them. Third, it acts.

4:23Every tool call reveals intent, timing, targets, and authority. Which systems were touched, in what order, with whose credentials. Fourth, observe. Traces and retries preserve the path, not just the result. Your observability, observe, ah, sorry, observe, observability. ability stacks, hard to say this word, records the agent's dead ends, its retries, and the queries that failed. The entire exploratory path. Fifth, retain. Debugging data quietly becomes a behavioral history. Those traces were kept to debug the model, but six months later, they're a minute-by-minute record of what the agent, and by extension, the user yourself, was trying to do. None of this is the task output.

5:08a shadow copy of the work and it's often more revealing than the output itself.

5:17And the second data stream doesn't stay distributed. It concentrates in three places. First, your agent orchestrator sees the whole task. Whatever coordinates the agent, your agent framework, your platform, watches every step, every tool call, every intermediate result. the single point that knows everything the agent did. Second, the tool providers each receive a slice of context. Every time the agent queries your email provider, your calendar API, your code host, that provider sees the query and the slice of context the agent sent along to make it. Your agent's questions become their logs and for anyone who's watched exactly all the questions the agents make indeed.

6:04detail. They provide a lot of context when attempting to make those queries, and they will make a lot of flawed queries and a lot of retries, and all of this information leaks to your data providers. Third, the observability systems preserve the trail, the trace pipelines, the eval harnesses, the debugging dashboards. They keep the full record, often with the longest retention and the broadest internal access, because they were built for engineers. debugging models, not for protecting user data. Now, if you think about this from an attacker's or a subpoena's perspective, three centralized repositories of behavioral data, each one a high value target, each one created as a side effect of making agents debuggable and useful.

6:51Which brings me to the sentence I want you to take home. The trace is the new metadata. We spent a decade learning the metadata, who talked to whom, when, and for how long can be just as revealing as content agent traces or metadata at a higher resolution, not just who talked to whom, but what was considered, what was tried, what failed and what the agent decided to do about it. What the agent did can be just as sensitive as the data it touched. Treat traces like the sensitive data that they are. So what do we do about this? Three principles stolen directly from how we build things at Signal. Principle one, minimize what the agent can see. Scope access to the task, not just the agent. Today, the common pattern is, create a service account for the agent, grant it broad standing authority, and let it call tools whenever it wants.

7:44That's ambient authority, and the agent's power is a property of its identity, not of the moment. Instead, I would suggest flipping this. Just in time, grant authority when the task starts, not when the agent account is created. short -lived credentials should expire before they can become ambient power minutes or hours not months narrowly scope the permissions you grant your agent expose the minimum records actions and time window the task needs not the whole api service and make sure these are revocable every delegation is a fast reliable off switch because the moment you can't revoke it it isn't a delegation anymore it's ownership this or the signal parallel here is private contact discovery. The server answers the question, is this contact on signal without ever learning the user's address book?

8:33The question gets answered, the knowledge doesn't transfer. Design your agent's tool access the same way, answer the task without transferring the entire kingdom.

8:44Principle two, minimize what the agent remembers. Make memory an explicit design decision because right now it's usually an accident. The default in most agent stacks is keep everything. The full context window gets persisted. The trace gets logged. The eval data gets warehoused. And nobody chose that. It's just what the SDK did. Choose instead, drop retrieved context when the task ends. The documents the agent pulled were useful for 20 minutes. They don't need to become a permanent history. Redact before the logging boundary, secrets, credentials. PII should never enter the trace pipeline in the first place. And don't log it and try to scrub it later. Decide at ingestion what the trace is allowed to contain.

9:31Keep outcomes longer than the process. Retain the result and the minimum evidence needed to explain it. Nobody needs the 17 dead-end queries. They need to know what was decided and why. And default retention to days, not forever. Make extension beyond that. time a deliberate exception with an owner and expiry not the default at signal message content doesn't live on our servers after delivery even before delivery we have all all messages that are undelivered have an expiry time built in so ephemerality isn't the is it isn't a feature flag it's the design and your agent's memory should have to justify its existence in the exact same way

10:14finally principle three minimize who can see the agents work protect the work path and not just the final output the left column is the default behavior centralize everything one service reads every tool call full traces become the default evidence and one breach exposes the complete behavior graph every task every user every decision in one place that is the surveillance architecture wearing a debugging costume The alternative, partition by design, end -to -end protection where the architecture allows. If the agent is mediating between two parties, it doesn't need to see the content to route the work. Same lesson with sealed sender, confidential execution when the plain text must be processed.

11:03When the agent genuinely needs usable data to reason over, run that reasoning where the infrastructure operator can't see it. Enclaves and confidential computing exist exactly the same way. for this purpose. And minimal, structured events instead of raw traces. Your audit and compliance systems don't need the agent stream of consciousness. They need to know what happened. Design the evidence your systems emit. Don't just record everything and hope the access controls hold. Because access controls are a promise, whereas architecture is actually a guarantee. And since this is the security and compliance track, or at least that's one of the tracks tagline, I want to address a common objection that compliance requires logging. Yes, compliance requires evidence, but it doesn't require a behavioral transcript.

11:51And there's a difference in it. It's important. So you should record the authority of which scope permission allowed this action. That's the delegation, not the grant. The policy that said yes. Record the control, which policy check passed or blocked it, and the guardrail decision, not the data that flowed through it. Record the outcome, what change. changed without storing the entire path. The write that happened, the message that was sent, the record that was updated. An auditor wants to know that the write controls existed and fired correctly. They don't need, and under data minimization regimes, often shouldn't have minute-by-minute transcript of the agent's reasoning over user data. When you design evidence instead of hoarding traces, compliance gets stronger. The records are smaller, it's easier to read, easier to protect, and harder to misuse.

12:37fidelity traces aren't an audit trail, they're liability with a retention policy.

12:43So here's the checklist. Five moves you can start this quarter. One, inventory every data source your agents can reach. Not just the tools you gave them on paper. They're very good about getting through one tool to find another tool. So you want to document the actual reachable surface, including what your tools can reach transitively. And that one's important to collect. You can't minimize what you haven't mapped. 2. Replace standing access with task-scoped credentials. Find the service account with broad permanent grants and convert them to just-in-time, short-lived, narrowly scoped delegations. And this is the highest leverage change on this list, just making sure that what you're granting your agents is only for the time you've asked them to do a specific thing. 3. Redacted ingestion and shortened trace retention.

13:31Put the redaction before the login boundary and return. traces only for days by default if someone needs longer ask them to justify it ask them to be an owner and have a default expiry for that time four ask exactly who can read your agent traces name the humans and the systems include the observability observability vendor the eval pipeline and anyone with a production database access if the list surprises you that's your finding five harden the orchestrator as your highest value target. It sees every task end to end. It deserves the security investment proportional to what it knows. Isolation, auditing, minimal standing privilege of its own. Do these five and you haven't solved the agentic internet, but you stop building the dossier by default.

14:19Now the honest caveat, because I don't want to oversell this, agency requires plain text somewhere. Encryption protects data in transit and at rest. It's necessary but not sufficient. An agent still needs usable data to decide and act. The model has to read the email to summarize it and to see the code to fix it. You can shrink that window, like we've just talked about, task scope, ephemeral, and partitioned, but you can't eliminate it. The hard boundary becomes data in use. That's why the third principle matters most in the long run, confidential execution, enclaves, and architectures where the party operating the infrastructure can't see the computation. That's the frontier. The question though, isn't whether we can keep agents from ever seen data, it's whether we can build them so that seen data is momentary, scoped and unrecorded instead of permanent, total and logged.

15:11In the long run, we should all aim to move the agent to the end user instead of the user's data to the agent. While confidential execution and enclaves are useful stop gaps until we have end user computers capable of running these frontier agents, only raise the cost of collecting data rather than fully guarantee it cannot be collected. Which leaves the question I started with and the one I would love to have discussions with you about afterwards. Can we build useful agents without building permanent behavior of glaciers? At Signal, we proved that a communication system can be enormously useful while knowing almost nothing. And I think the agentic internet can learn the same lesson, but only if we architect for ignorance deliberately. before knowing the dossier has become the business model.

15:57Architects, there's nothing to take. Thank you.