We built Signal to not know things. Agents want to know everything.

Good afternoon, I'm Ehren, 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 a little 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 is one less thing that can be stolen, leaked, mishandled, or subpoenaed. You can't lose what you never had. These two curves point in opposite directions, and every team building agents has been 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. Broad context makes planning feel intelligent. The agent reads your email threads, your docs, your git 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, it 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, you'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 is genuinely impressive. Everyone who's tried it out knows 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, need to 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. So at Signal, we came at this 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 routing information needed to deliver them. We can't read your messages, which means we can't hand them to anyone who asked. SalesCender goes further, the server doesn't even learn who is messaging whom. Sender 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 private set intersection and private information retrieval. But the point isn't these specific mechanisms, it'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. Now 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. Every 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 stags 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, it's a shadow copy of the work, and it's often more revealing than the output itself. And 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. It's 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 in detail, 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. Which brings me to the sentence I want you to take home. The trace is the new metadata. We spent a decade learning that metadata, who talked to whom, when, and for how long, can be just as revealing as content. Agent traces are metadata to 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. That'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 needs a fast, reliable off switch, because the moment you can't revoke it, it isn't a delegation anymore. It's ownership. 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? The 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. Principle 2. 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 contacts when the task ends. The documents the agent pooled 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. Keep 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 messages that are undelivered have an expiry time built in. So, ephemerality 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. Finally, principle three. Minimize who can see the agent's 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 as Sealed Sender. Confidential execution when the plain text must be processed. When 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 for this purpose. Minimal, structured events instead of raw traces. Your audit and compliance systems don't need the agent's 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 I want to address a common objection that compliance requires logging. Yes, compliance requires evidence, but it doesn't require a behavioral transcript. And 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 changed, without storing the entire path. The right that happened, the message that was sent, the record that was updated. An auditor wants to know that the right 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. Full fidelity traces aren't an audit trail, they're liability with a retention policy. So 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 going 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. Two, 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. Three, redacted ingestion and shortened trace retention. Put the redaction before the login boundary and retain 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 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've stopped building the dossier by default. Now 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 scoped, 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 overseeing data. It's whether we can build them so that seen data is momentary, scoped, and unrecorded, instead of permanent, total, and logged. In 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. They 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 dossiers? 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 dossiers become the business model. Architect so there's nothing to take. Thank you.