The Shape of Context in Agentic Authorization

Phil Windley // Mon Jul 6 10:04:00 2026 // agentic+ai authz authorization ai identity context

This post is part of a series on using dynamic authorization to control and coordinate AI agents. See the series recap to find other posts in this series.

Agentic AI is still early, and the architectures, protocols, trust models, and operational patterns for agent-based systems will almost certainly change as organizations gain experience with them. The details of MCP, tool invocation, delegation, agent-to-agent interaction, and runtime governance are still being worked out. But the broad authorization problem is already visible: agents need a way to decide what they are allowed to do, what context matters, whose authority they are exercising, and when a requested action must be refused. Most of the difficulty in answering those questions lives in one word from the PARC model: context. A reviewer of a draft of my upcoming book on authorization pushed on exactly that point, arguing that I had underplayed how complicated context becomes once agents are talking to agents, and he was right; this post is my attempt to think through that complication.

Agentic systems change the shape of authorization context. In a conventional application, the policy decision often begins with a familiar question: can this employee, application, or service perform this action on this resource? The principal, action, and resource are usually known to the system in advance, and the relevant context can be collected from a small number of well-understood sources. The decision is nearly self-contained, and an engineer can reason about it by reading a small number of policies.

The signals multiply

Agentic systems are different. An agent may act on behalf of a person, another agent, an organization, or some combination of delegated authorities. It may call tools, consult other agents, transform data, and produce intermediate results before it ever touches the resource that ultimately matters. The principal, action, and resource are no longer fixed at the start; they emerge as the agent plans, and the context that governs each step arrives as a flood of signals rather than a tidy record.

Those signals come in many kinds, and they come from many places. A single decision might have to weigh the initiating principal's intent, the scope of delegation, consent constraints, personal preferences, organizational policy, data sensitivity, tool capabilities, resource state, risk signals, provenance, and the guardrails imposed by the agent platform or the enterprise. Some of these are stable and institutional, such as a company's data-handling rules. Others are ephemeral and task-specific, such as the fact that this particular request is two hops removed from a human who only asked for a summary.

It helps to sort these signals by what they actually constrain. Some describe who is really asking and under what authority, such as delegation scope, initiating principal, and consent. Some describe what is at stake, such as data sensitivity, resource state, and tenant boundaries. Some describe how much to trust the request itself, such as provenance, risk scores, and the guardrails the platform is already enforcing. Naming the categories does not make the decision simple, but it keeps the flood from looking like undifferentiated noise.

Signals move through a mesh

Listing the signals is the easy part. The harder question is where each one is consumed, because a request rarely travels in a straight line from a person to a resource. It passes through a mesh of agents, each of which may plan, delegate, and call the next agent in turn. A signal that is decisive at one hop may be irrelevant at the next, and a signal that no intermediate agent cares about may be exactly what the resource needs to see.

Consider a person who asks a coordinating agent to reconcile an invoice, which calls a data-gathering agent, which in turn calls a tool that reads from the finance system. The person's intent to "reconcile, not pay" has to shape what the coordinating agent is even willing to plan, but it cannot stop there; it has to travel all the way to the last hop so the finance system itself refuses a payment even if some agent in the chain proposes one. The delegation scope has to make the same journey, arriving intact so the finance system can confirm the request stays inside it. A freshly computed risk score on the intermediate data, by contrast, may matter only to the agent that produced it, and never needs to leave that hop at all.

So signals have distinct audiences. Some are steering signals that constrain the behavior of the next agent in the chain, and they need to be carried forward, narrowed, and re-evaluated at each hop. Others are enforcement signals that matter only at the point where authority finally lands on a resource, and they need to survive the whole journey without being flattened or forged along the way. And some are both: the intent in the example steers the coordinating agent's early planning and still has to be enforced at the finance system, so it must be narrowed as it travels and honored when it arrives. Treating every signal as if it belonged everywhere produces both over-sharing and under-enforcement. Deciding, per signal, who consumes it and where is a large part of designing an agentic authorization system.

There is also a limit to how much of this the calling mesh gets to decide. The system behind an API or MCP server almost always has its own authorization, and it may be governed by a different organization entirely. The MCP server is a way to reach that system, not the place where authority finally lands; the finance system, the database, or the file server enforces its own policy no matter what the agents upstream concluded. Authorization here is layered rather than singular, and no single decision point speaks for all of them.

This is where policy constraints that can be queried along the way earn their keep. If a downstream resource can advertise what it will and will not permit, or answer a "would this be allowed?" question before an agent commits to a plan, the agents upstream can shape their behavior to fit instead of discovering the boundary only when an action is refused. It also raises the bar for the signals a request carries, because the delegation and context have to stay legible to a policy engine the initiating organization does not control.

A non-directed world

There is a deeper shift underneath all of this. Traditional access control is directed and largely static: the system knows that Alice has access to the finance application, the finance application knows Alice, and the relationship is established before either of them does any work. The set of principals is small and enumerable, and the resource can hold a model of who is allowed to knock on its door.

Agentic systems are non-directed. A resource backend has no reliable way to know, in advance, which agent will arrive in the next minute or on whose behalf it will be acting. The requester may be an agent that did not exist 5 minutes ago, spun up to handle one task and then discarded. In that world, identity established ahead of time cannot carry the weight it used to, and the resource has to decide what to allow based on the authority and context presented at the moment of the request.

This is exactly where dynamic authorization earns its place. When the resource cannot pre-enroll every principal, the decision has to move to request time and rest on portable evidence: who initiated this, what were they trying to do, what delegation connects them to the agent now asking, and what constraints ride along with it. The point of the signals is to reconstruct, at the moment of the request, the accountability that a directed system used to establish in advance.

Complexity doesn't change who decides

Faced with dozens or hundreds of signals in a single request, it is tempting to conclude that the decision itself has outgrown human-authored policy, and that we should let a model weigh the signals and decide. I think that conclusion mistakes a hard engineering problem for a change in who should be in charge. The volume of context is real, but it is an argument about how we gather, normalize, and route signals, not an argument for moving the judgment about what is allowed into a system whose reasoning we cannot inspect or reproduce.

The work that genuinely is hard belongs on the input side of the decision. Assembling the signals, resolving them into a consistent shape, summarizing evidence, and scoring risk are all tasks where models and other tooling can help enormously, and where an agent's flexibility is an asset rather than a hazard. What should stay deterministic is the final question: given this principal, action, resource, and assembled context, is the action permitted? A policy that answers that question can be read, tested, and explained after the fact, which is precisely what the people whose data and money are at stake are entitled to.

Keeping that line clear does not make the policies simple. Deciding which signals a policy consults, and trusting that they were gathered honestly, is a substantial design problem, and it will pull more structure and more tooling into the space around the decision. But the decision stays somewhere a human can point to and understand. Complexity in the context is a reason to build better machinery for handling signals; it is not a reason to hand the judgment itself to a system that cannot tell us why it said yes.

Agentic AI will reshape almost everything about how context is gathered and carried, and much of what I have described here will look primitive in a few years. What I do not expect to change is the shape of the obligation. When authority lands on a real resource on behalf of a real person, someone has to be able to say why the action was allowed, in terms that person could check. Getting the context right is how we make that answer possible; keeping the decision inspectable is how we make sure it stays true.

Photo Credit: The Shape of Context from ChatGPT (public domain)

Manifold API and Sensor Network: Two New Repos

Phil Windley // Tue Jun 9 09:14:00 2026 // picos manifold iot lorawan sensor+network krl testing

When I wrote about the BYU capstone project that built a conversational interface for Manifold, I glossed over something that had to happen first: the platform itself needed to be in shape before students could build a natural language layer on top of it. There were still some loose ends that needed to be cleaned up. That work is now complete, and I am releasing it as manifold-api on GitHub.

Building Fuse and the temperature-network taught me something that did not make it into early Manifold: pico networks need communities. Fuse organized its picos into fleets—a fleet pico owning a collection of vehicle picos, each with its own state and event routing. The temperature-network did the same thing with sensor devices grouped by location. Early Manifold was focused on things; communities were a later addition that never fully developed. Each of those systems ended up managing its own pico hierarchy, its own notification plumbing, and its own version of the same community lifecycle logic. This update is the attempt to get that right: communities are now a first-class part of Manifold, with a delegation interface that lets domain repos specialize them without reimplementing the plumbing underneath.

The biggest architectural change in this update is the notification platform. Previously, domain-specific rulesets called Twilio or Prowl directly. Each network managed its own credentials and delivery logic, which meant the same plumbing was duplicated across repos. The new approach centralizes everything on the Manifold pico: any thing or community can raise a manifold:add_notification event with a subject, message, and identifying attributes, and Manifold handles the fan-out to whichever channels are enabled for that pico (inbox, SMS via Twilio, push via Prowl). Notification channels are opt-in per subject, so a sensor community can enable SMS alerts without every other pico in the network generating noise. This is a cleaner separation of concerns, and it means domain repos no longer need to know anything about how the owner gets notified.

The other major addition is automated bootstrap. The old manual three-step initialization—create tag registry, create owner pico, register tag server—is now handled by a single bootstrap ruleset installed on the root pico. In practice this means spinning up a fresh Manifold instance goes from a sequence of API calls that had to be executed in the right order to a single ruleset install. The test harness depends on this; it would not be practical to run a clean Docker container for every test run if setup were manual.

Testing Against a Real Engine

The test harness in manifold-api is a TypeScript NPM package that spins up a standard pico-engine in Docker, mounts the repo's KRL files directly, runs bootstrap and lifecycle scenarios, then tears the container down. Because the engine mounts the KRL as file:// URLs, you can edit a ruleset and re-run without rebuilding the image; the iteration loop is fast. The npm test command runs the full suite: KRL syntax parse gate, Docker startup, bootstrap (tag registry, owner, Manifold pico), and thing/community create/add/remove/delete flows. The current scenarios give you a regression baseline before touching any of the core rulesets.

Sensor Network Moves Inside Manifold

Once the platform was solid, I looked at my old temperature-network repo—the one behind the Dragino LoRaWAN sensor network I put in place at a remote pump house—and saw an obvious refactoring opportunity. The original approach managed its own pico hierarchy independently of Manifold, because at the time Manifold's community support was not developed enough to build on. That is no longer true. The new sensor-network repo replaces temperature-network entirely, rewriting all its rulesets to treat sensor communities and devices as ordinary Manifold community and thing picos.

The design is a clean layering. Manifold handles the pico hierarchy, subscription management, thing and community lifecycle, and notifications. The sensor network adds sensor-specific behavior on top. Installing io.picolabs.sensor.network_bootstrap on the Manifold pico is the only requirement to get started. From there, raising a sensor:create_community event delegates to Manifold's generic community machinery to create a sensor network community pico.

To create a new sensor, raising the sensor:initiation event on a community's sensor channel delegates to Manifold's thing creation with a callback. The community receives community:thing_created and finishes sensor-specific setup, installing the appropriate router ruleset for the sensor type, setting up threshold monitoring, and enabling the requested notification channels. Threshold alerts are routed using manifold:add_notification rather than calling Twilio or Prowl directly. The sensor-network rulesets do not know the details of how the owner gets notified.

Supported hardware today is Dragino LoRaWAN sensors: LHT65 (temperature/humidity), LSE01 (soil), LSN50 (multi-purpose), and WL03A-LB (water leak). Each sensor type gets a router ruleset that decodes payloads and raises sensor domain events. Adding a new sensor type requires registering it in io.picolabs.sensor.community and providing a router ruleset—the rest of the stack does not change.

Shared Test Infrastructure

The sensor-network test harness reuses manifold-api's infrastructure directly via dependsOn. When npm test runs in the sensor-network repo, it mounts both repos into a single pico-engine Docker container: manifold-api provides the platform rulesets, sensor-network provides the sensor-specific ones. The test suite bootstraps a full Manifold installation, creates a sensor community, initiates sensors for LHT65, LSE01, and LSN50, and tears everything down. Because the platform and the domain layer share a test container, integration failures between them surface immediately rather than waiting for production. A stable Manifold API means sensor-network's tests can focus on sensor behavior instead of re-testing platform primitives.

Future Work

Three areas are on the near-term roadmap. The first is bringing over the Personal Data Store (PDS) ruleset from Fuse and updating it for the Manifold model. The original PDS was more than a profile; it was a structured data contract for every pico, organizing state into a profile slice, a namespaced elements store for app and domain data, and a per-ruleset settings store. Rulesets wrote their configuration data using PDS events rather than touching entity vars directly, which meant the PDS owned the data and could enforce schemas, react to changes, and clean up on uninstall. The shared schema part is what made this useful: when a ruleset declared its data shape through the PDS, other rulesets and the platform could discover what that pico knew how to do and what data it held without hard-coding assumptions about what was installed where.

Right now Manifold has none of that. Profile and configuration data is scattered: wrangler stores a pico name in myself(), the Manifold pico stores names in its thing and community registries, and individual rulesets like SafeAndMine maintain their own contact info. Each domain repo works around the absence of a shared data contract by stitching together entity vars and event attributes on its own. A proper PDS ruleset installed on every pico would replace that sprawl with a single queryable API, give sensor-network a reliable way to describe its things, and, more importantly, give any future domain repo a foundation it can build on without reinventing storage conventions from scratch.

The second item is a Home Assistant integration. I have been running Home Assistant alongside my sensor network and the obvious next step is an API layer that lets Home Assistant read sensor state and trigger automations based on it. Home Assistant has a well-documented REST API model, and the Manifold thing and community queries map cleanly onto it; it is more a matter of building the bridge than solving a hard architectural problem. Longer term, I think we could recreate much of what the original Manifold web app provided—dashboards, thing management, notification configuration—directly inside Home Assistant, which already has a capable UI and a large ecosystem of integrations.

Further out, Manifold needs to support multi-tenancy and proper authentication. The current model assumes a single owner per engine instance, which works fine for a personal deployment but limits how broadly Manifold can be used. Proper authentication and richer authorization—controlling who can raise events and query state on which picos—is the deeper requirement. That is not something Manifold can solve on its own; it requires support from the pico engine. The engine would need to enforce identity and access control at the channel level before Manifold could reliably build multi-tenant behavior on top of it.

The pattern here—a domain repo that treats Manifold as a dependency and shares its test infrastructure—is intentional. Any pico-based application that needs communities, notifications, and thing management should be able to build on manifold-api without forking its bootstrap logic or reimplementing its notification plumbing. The goal is to make Manifold a framework that domain repos build on, not a collection of utilities that each repo copies. These two repos are the first concrete demonstration of that working end to end.

Photo Credit: Sensor network on Manifold from the sensor-network repository documentation (public domain)

AI Integration in Picos Starts with Events

Phil Windley // Tue Jun 2 09:06:00 2026 // picos fuse agentic+ai internet+of+things

When I think about integrating AI into pico-based systems, the temptation is to imagine some deep architectural rework—a new runtime, a new protocol, some fundamental change to how rulesets execute. But I think the right starting point is already there in the architecture: events. Picos already send and receive events. Claude routines already listen for triggers and respond with actions. Connecting them is not a research problem; it is an integration problem, and a shallow one at that.

The simplest version looks like this: a pico fires an event, a Claude routine receives it via webhook, does some reasoning, and posts a response event back to the pico's event channel. The pico's ruleset handles the response the same way it handles any other event: routing it, acting on it, updating state. Nothing in this picture requires changes to the pico engine or the Claude API. Both sides speak events; the webhook is just the seam between them.

I saw this pattern clearly when I was building Fuse, the connected-car application built on picos. Fuse picos held the car's data and fired events when interesting things happened: location changes, diagnostic codes, ignition on and off. The missing piece, looking back, was anything that could reason over those events rather than just route them. An AI routine that receives a pico event carrying a diagnostic code and responds with an interpretation—or a question—is exactly the kind of capability Fuse needed and couldn't easily have in 2014. Fuse sent notifications, but bare notifications are not very useful to most people. An AI layer that enriches a location event with context ("you're near the dealership where your recall service is overdue") or translates a diagnostic code into plain language and a recommendation would have made Fuse dramatically more useful to drivers.

Project Neck Pain showed something similar from a different angle. That project used picos to hold personal health data: appointments, sensor readings, notes. The pico owned the data; it didn't live in some third-party health app's database. But ownership without intelligence is just storage. The interesting question was always: what should happen next? We built rules that would automate some of the drudgery of dealing with the healthcare system. But, it proved to be too brittle. AI changes that completely. An AI routine that receives an event—a symptom log, a missed appointment, a change in a sensor trend—and responds with an inference is not replacing the pico's role. It is extending it. The pico remains the locus of identity and state; the AI contributes reasoning that the ruleset alone can't do.

This suggests a natural progression for AI integration in pico systems.

1. The first step is the webhook pattern I described: AI as an external actor that exchanges events with the pico. This just uses the http:post() to call a URL.
2. The second step is tighter: rather than an external routine, a KRL action sends a request to Claude with a callback event URL, and a separate rule handles the response when it arrives asynchronously. This fits how picos actually work—rules fire in response to events, and Claude's processing times make a synchronous call inside a rule impractical. The callback event is the right model; Claude becomes a capability the ruleset can invoke, not a separate system to coordinate with by hand.
3. The third step is the one I find most architecturally interesting. At this stage, Claude uses pico query endpoints as tools to read and write persistent state across sessions. The pico is the memory. This matters because most AI memory schemes are ad hoc, using a database or even a Markdown file for memory. Picos already have the right structure: named, persistent, owned by a specific identity.
4. The fourth step follows from the third. If Claude holds a longer-running task and the pico holds the relevant state, then Claude can fire events into the pico graph to make things happen—not just to return data to the ruleset, but to orchestrate behavior using the pico's event channels the way a person would.

What makes this progression coherent is that picos already have the properties that make for an interesting AI integration.

• They have persistent identity—each pico is a specific thing with a stable address.
• They have owned state—the data inside a pico belongs to the pico, not to a platform that might revoke access or change terms.
• And they are event-driven—which is exactly the interface AI systems are designed to plug into.

I've argued for years that picos are the right substrate for building systems where people and things control their own data. Adding AI reasoning to that substrate doesn't change the argument; it strengthens it. An AI that reasons on your behalf, over your data, stored in your picos, is a fundamentally different thing from an AI that reasons on your behalf using data held by someone else. The first is an agent working for you. The second is an administrative intermediary with a language model grafted on.

Picos form natural hierarchies. A car pico holds what the car knows; the household pico that owns it can query across all its children—car, health devices, calendar—and give an AI a cross-domain view that no flat memory store provides naturally. Each pico in the hierarchy can have its own AI context and reasoning scope, and parent picos can aggregate across children. That hierarchy also encodes privacy boundaries: an AI reasoning on behalf of the household can traverse the graph with appropriate permissions, but no external system can simply reach in. The ownership structure is not metadata bolted on; it is the architecture.

The webhook integration is worth building right now because it establishes the semantics that the deeper integrations depend on. Which events are meaningful enough to route to an AI? What does a useful response event look like? How does the ruleset act on it? Answering those questions with a simple prototype clarifies the architecture far better than designing it on paper. That is how picos got to where they are today, through real use cases that forced the design into focus. The AI integration will be no different.

Photo Credit: Owned AI Agents via Picos from DALL-E (public domain)

Internet Identity Workshop XLII Report

Phil Windley // Mon Jun 1 09:16:00 2026 // identity iiw agent ai sedi

The Internet Identity Workshop met for the 42nd time at the Computer History Museum in Mountain View, California, April 28–30, 2026. As always, the Open Space unconference format let the agenda emerge from the people in the room. And, as always, the room delivered. Over three days and fifteen slots, participants convened 158 sessions spanning identity architecture, agentic systems, legal frameworks, cryptographic foundations, and the human stakes that tie all of it together.

We also held the second Agentic Internet Workshop (AIW2) on Friday, May 1, immediately following IIW. Like the first AIW last October, it used the same unconference format, this time with a sharper focus on how identity infrastructure supports autonomous agents operating on behalf of people.

Attendance

IIW 42 brought together 287 participants, matching last fall's IIW 41 exactly. That consistency is worth noting. There are lots of identity conferences now and the hype cycle pulls attention in every direction, but the identity community keeps showing up. The number reflects sustained interest in solving real problems. Because that's what IIW offers: space to solve problems. It's a workshop in thr true sense of the word.

The hallway track was as rich as always. Some of the best conversations at IIW happen between sessions, at lunch, or during the demo hour, where people pull out laptops and show working code rather than slides. One of the reasons that meals are included at IIW is to keep the energy high and the conversations flowing.

Geographic Diversity

The geographic picture at IIW 42 was familiar in its broad strokes. The United States accounted for 229 of 287 attendees, with California leading the way at 119. San Francisco (19), San Jose (14), and Oakland (8) anchored the Bay Area contingent, while Seattle (7) and Los Angeles (7) rounded out the West Coast presence. Utah contributed 14 attendees, Texas 12, and Massachusetts 12, reflecting the distributed geography of the identity community within the U.S.

Internationally, Japan continued its strong showing with 12 attendees, primarily from Tokyo (9). The United Kingdom sent 7, Canada 5, Switzerland 4 (all from Zurich), Poland 3, and Germany 3. We saw participation from South Korea and several other countries as well. The attendee map tells the story visually: clusters in North America and Europe, with welcome pins in Asia, South America, Africa, and Australia.

I am glad to see the map filling in beyond the usual corridors, but there is still work to do. Identity challenges are global, and the solutions we build at IIW benefit from hearing voices that face different regulatory environments, infrastructure constraints, and cultural expectations. We continue to support IIW-Inspired^TM regional events like DID:UNCONF Africa and DICE to extend the conversation. If you know identity builders in underrepresented regions, point them our way.

One concrete way to help is through the IIW Global Participation Scholarship, which funds travel and registration for attendees from regions that are underrepresented. The scholarship makes a real difference; it brings perspectives into the room that change the quality of the conversation for everyone. If your organization benefits from the work that comes out of IIW, consider sponsoring a scholarship for IIW 43. The identity infrastructure we are building is meant to serve people everywhere; the people building it should reflect that.

Topics and Themes

The agenda at IIW is built fresh each morning. Participants write their session titles on index cards, announce them to the room, and place them on the agenda wall. That emergent structure is one of the things that makes IIW work; the topics reflect what people are actually building, struggling with, and thinking about right now. Here's a recap of what the community brought to the table this time.

SEDI and the duty of loyalty were prominent throughout the workshop. Sam Smith led sessions on KERI/ACDC bulk issuance for SEDI privacy and on cryptographic foundations, while separate conversations explored SEDI's legal framework, its duty of loyalty provision, and how it connects to protocols like MyTerms. As I wrote in Data Protection Missed the Point; Loyalty Gets It Right, the duty of loyalty shifts the basis for regulation from data to the relationship. That idea had real traction in the room, with people working through what it means for implementation, not just theory.

Agentic identity was everywhere. Sessions covered agent taxonomy (what counts as an agent? ephemeral versus persistent?), OAuth for sub-agents, AI agents and open banking, agent storyboarding, and agentic identity credentials. Drummond Reed introduced the Decentralized Trust Graph and First Person Project. Dick Hardt led an AAuth deep dive, exploring his open protocol that gives agents their own cryptographic identity without pre-registration or shared secrets. The question running through all of these was not whether agents need identity; it was how we build identity systems that let agents act on behalf of people without becoming another layer of administrative intermediation. A Dilithium demo showed server-side user-agents operating at speed, and multiple sessions explored how authorization models need to adapt when the entity presenting a credential is not a human but a piece of software acting with delegated authority.

MyTerms, the newly published IEEE 7012 standard, had a strong showing across all three days. Doc Searls led MyTerms 101 and 101.5 sessions, and Iain Henderson ran a session connecting VRM, MyTerms, and fiduciary agents. MyTerms gives individuals a protocol for proposing terms to websites as first parties rather than clicking through adhesion contracts. The connection to SEDI's duty of loyalty—which I explored in a post from VRM Day—was a recurring thread. Together, they start to look like operational infrastructure for digital relationships where people have standing as participants, not just data subjects.

The standards and protocol track was robust. OpenID4VC had sessions covering updates and implementation details, including server-to-server issuance via OpenID4VCI. Aaron Parecki ran OAuth 101 and John Bradley covered FIDO and WebAuthn. The W3C Verifiable Credentials Working Group held a session on its new charter and current work. Frederik Krogsdal Jacobsen ran sessions on formal security verification of specs and on interaction endpoint authorization via first-party apps. Content authenticity also had a visible presence, with sessions on the C2PA standard and the Content Authenticity Working Group (CAWG), plus an originator profile session; as AI-generated content proliferates, provenance is becoming an identity problem whether the identity community planned for it or not. These sessions reflected a community that is past the design and implementation phases and into the details of making things work at scale.

On the cryptographic front, we saw renewed energy around:

• Post-quantum readiness—a Dilithium demo and sessions on cryptographic agility showed the community taking the transition seriously, not just talking about it.
• Zero-knowledge proofs—ZKP 101 sessions, a ZKP age verification demo, and Sam Smith's session on misapplications of bare signatures and ZKPs for non-ephemeral case proofs.
• KERI and GLEIF—Kent Bull ran KERI + did:webs 101 with GLEIF, connecting decentralized key management to real-world organizational identity at scale.

Trust infrastructure surfaced as a theme in its own right. Erica Bjune led a two-part session on trust infrastructure as a public utility. Mike Leahy convened the first Fiduciary Commons session, working from first principles toward law. Joe Andrieu provided a digital fiduciary update. These conversations share a premise: that trust is not just a technical property of a protocol; it is a social and institutional arrangement that needs its own infrastructure. That framing resonates with the broader shift from building identity tools to building identity institutions.

The EUDI wallet drew attention with sessions on the German implementation and on wallet-level authentication and authorization. These sessions brought a European regulatory perspective into the room, grounding abstract wallet discussions in the specifics of what member states are actually building.

There were also sessions looking at identity at a more foundational level. Christopher Allen revisited SSI principles for the next decade in his "SSI 10th!" session. Denny Wong asked why personal identity matters in the era of AI. Eric Welton explored cognitive liberty and captive audiences through a First Amendment lens. Dean Saxe and Eve Maler convened a session on death and the digital estate, something that eventually concerns us all. And Wendy Seltzer led a session on identity and geopolitics, reminding us that the infrastructure we build operates within political systems that have their own ideas about who controls identity, a good counterpoint to the SEDI discussions.

The 101 sessions deserve a mention. IIW has always been a place where newcomers can get grounded, and this time the program included introductions to OAuth, OpenID Connect, FIDO/WebAuthn, ZKPs, SSI, OpenID4VC, authorization, and content authenticity. Steve McCown and Omri Gazitt ran particularly well-attended sessions. These 101 tracks are not filler; they are how the community renews itself and ensures that the deep-dive sessions in later slots have a prepared audience.

Demo Hour

One of IIW's distinctive features is the speed demo hour on Wednesday afternoon. Twenty tables, each with a numbered sign, fill the Grand Hall. Each demonstrator gives a five-minute demo, then the audience rotates to the next table. If you're disciplined, you can see 10 of the 20 demos over the course of an hour. It is loud and seemingly chaotic, but it works. Demo hour is about working code and running systems. You can tell a lot about a community by what it chooses to demo.

This time, the demo tables told a clear story: agents have arrived, and the identity community is building the infrastructure to make them trustworthy. Niki Niyikiza showed Tenuo's attenuating authorization tokens that cryptographically narrow an agent's capabilities at each delegation hop. Dick Hardt demoed AAuth, an open protocol giving agents their own cryptographic identity without pre-registration or shared secrets. Kenta Takahashi and Takayuki Suzuki demonstrated Proof of Human Delegation, using biometrics to prove that an agent acts on behalf of a specific person within their stated intent. Ankit Agarwal showed KYAPay, a protocol for agent authentication and tokenized payments. And Alex Olivier and Atul Tulshibagwale demoed a reference implementation of the OpenID AuthZEN MCP Profile for fine-grained, parameter-level authorization before an MCP server executes a tool. The common thread: agents need identity, authorization, and accountability, and those cannot be afterthoughts bolted on later.

Wallets and credentials showed up in force. Rob De Feo showed an AI agent completing an age-verified purchase and hiring a car through the EUDI Wallet via OpenID4VP. Jarek Sygitowicz and Flora Frend demonstrated practical EUDI implementations using the Digital Credentials API on iOS and Android with fallback to legacy eIDs. Dmitri Zagidulin showed Freewallet, a free, open-source web wallet for DIDs and verifiable credentials. Christopher Allen demoed XIDs, DID-inspired identifiers built on Gordian Envelope that give holders, rather than issuers, control over what gets revealed through selective disclosure and redaction.

Several demos pushed into new territory. Iain Henderson and Jon Udell showed MyKey combined with MyTerms and XMLUI, connecting decentralized identifiers to privacy terms and a semantic UI framework. David Condrey's WritersProof captured cryptographic proof of human authorship by entangling identity, keystrokes, and timing into an unforgeable hash chain. Mahesh Balan showed MyWellWallet, a patient-owned health wallet using local LLMs and FHIR to give people an intelligent view of their health data without sending it to the cloud. And Deb Bucci demoed an execution-time delegation harness that evaluates whether a delegated action still aligns with a person's intent at the moment it is requested. Twenty tables, twenty teams showing things that did not exist a year ago.

Looking Ahead

Because IIW runs on Open Space, every workshop is a fresh expression of where the community actually is. No program committee selects topics months in advance; the people who show up decide what matters that morning. That is what makes each IIW genuinely new. The topics at IIW 42 reflected a community whose conversations were less about whether the architecture is right and more about how to deploy it, govern it, and make it work for people who will not attend an unconference. SEDI's duty of loyalty, MyTerms, agentic identity, post-quantum readiness, the EUDI wallet: these are implementation challenges now, not research topics. The people in the room are doing the implementation.

Huge thanks to everyone who convened a session, asked a hard question, showed a demo, or pulled someone into a hallway conversation. That is what makes IIW work, and it has been working for 42 editions now. The book of proceedings will be available soon with session notes, links, and other important details.

Mark your calendars: IIW 43 is November 3–5, 2026, with AIW3 on Friday, November 6. Tickets will be on sale in about a month. Sponsorships are available now. Until then, keep building.

You can check out all of Doc's photos of IIW 42 for a visual report on who, what and when.

Photo Credit: IIW XLII Photos from Doc Searls (CC BY 4.0)

Enhance, Duplicate, or Replace? None of the Above.

Phil Windley // Tue May 19 16:54:00 2026 // sedi digital+identity utah credentials wallets

Alan Mayo's latest Identity 2.5 newsletter poses a useful strategic question: when we build digital identity reuse, are we enhancing existing infrastructure, duplicating it, or replacing it? He maps three approaches onto those choices: networked identity enhances, credential/wallet identity duplicates, and decentralized identity replaces. He then places Utah's State-Endorsed Digital Identity (SEDI) squarely in the third category and concludes that networked identity is the obvious, lowest-risk path forward. The framework is a good lens. But his classification of SEDI is wrong.

What Mayo Gets Right

Mayo is right that societies already have digital identity. Government agencies, banks, and healthcare systems hold digital records of who we are; what they issue to us are physical documents and credentials that allow a basic form of identity reuse. The strategic question is not whether to create digital identity but how to let people reuse it effectively. That reframing is valuable because it cuts through a lot of the hype that treats digital identity as something we still need to invent.

He is also right that wallet-based credentials introduce real operational complexity. Lifecycle management, revocation, device binding, recovery, verifier trust, wallet trust, and credential freshness all matter. His critique of naive "just put credentials in a wallet" thinking is fair; a high-assurance identity ecosystem cannot rely on static credentials floating around indefinitely. Utah's own mobile driver's license work already recognizes these problems by emphasizing consent, selective disclosure, anti-tracking, and state-signed credentials under individual control.

And he is right that institutional trust does not disappear. SEDI still needs authoritative issuers, governance, endorsement rules, certification, relying-party accountability, revocation, and legal frameworks. Even the ACLU's analysis of Utah's legislation praises it as a legal and governance framework with important privacy protections, not as magic cryptography that makes institutions irrelevant. None of that goes away in a world with digital credentials. The question is how institutional trust gets expressed and who controls the presentation.

Where the Framework Breaks

Mayo's big mistake is classifying SEDI as "Decentralized Identity" in the purist replacement sense. He characterizes that category as individual-held identity, cryptographic security, self-sovereignty, and no central control. That badly misrepresents first person identity in general and SEDI's architecture in particular. SEDI is not trying to eliminate institutional trust or replace government identity infrastructure. It is a state-endorsed legal and governance framework for digital credentials. The state still verifies, endorses, regulates, and defines duties for participants. That is not anti-institutional decentralization; it is public trust infrastructure with individual control over consent, disclosure, and the terms of the relationship.

He also conflates credential identity and decentralized identity in a way that obscures what SEDI actually does. SEDI is closer to a hybrid: credential-based presentation with state endorsement, legal duties, privacy protections, and governance. It is not simply duplicating current identity infrastructure into wallets, and it is not replacing identity infrastructure with cryptographic self-sovereignty. It sits outside Mayo's three-bucket taxonomy because it combines institutional authority with individual agency in ways his framework does not accommodate.

Mayo overstates the idea that credential systems make every phone wallet "a mini Identity Provider." A wallet is never the authoritative source of identity. Even with self-issued credentials, the authority rests with the individual issuing the credential, not the container. The wallet is a presentation mechanism; the issuer remains authoritative for the claims it signs. The hard problems of binding, revocation, and recovery are real, but they do not turn the wallet into a source of truth. They turn it into a presentation layer, one the individual controls rather than the institution.

He also misses SEDI's most important innovation, and it is not a technical one. SEDI's distinguishing move is law before technology. The point is not that new cryptographic techniques will solve identity. The point is that digital identity needs constitutional principles, fiduciary-like duties, voluntary adoption, non-tracking rules, selective disclosure, and enforceable accountability. As I wrote in A Legal Identity Foundation Isn't Optional, SEDI provides a legal base layer for first person digital trust. The ACLU did not praise Utah's legislation because of its cryptographic architecture; they praised it because it adds civil-liberties protections to digital identity. The duty of loyalty provision places a fiduciary obligation on institutions that rely on a state-endorsed digital identity. That is a governance innovation, not a technology choice.

Networked Identity Is Not the Obvious Answer

Mayo treats networked identity as the obviously practical path, but that model has its own structural weaknesses. A central switch creates a single point of dependency and failure. Online-only availability means the system breaks when the network does. Relying-party accreditation creates bottlenecks that limit who can participate. And a model where every identity transaction runs through a network switch creates inherent opportunities for surveillance, correlation, and gatekeeper control. SEDI is partly a response to exactly those risks.

The Scandinavian BankID systems that Mayo points to work well in small, high-trust societies with strong institutional foundations. They are real accomplishments. But they also concentrate identity infrastructure in banking consortiums, require online connectivity for every transaction, and give the network operator visibility into every authentication event. Those are acceptable tradeoffs in some contexts. They are not acceptable when the policy goal is individual control, minimized disclosure, and resistance to tracking.

Networked identity is also inherently national; each country's BankID is a separate system tied to its own banking consortium. Cross-border use requires additional federation infrastructure that reintroduces much of the complexity Mayo attributes only to credential and decentralized systems. A networked model can be useful for some transactions, but it does not automatically win when the policy goals include individual control, minimal disclosure, offline capability, cross-border portability, and resistance to surveillance.

What SEDI Actually Is

None of this means SEDI is the clean best-of-all-worlds answer. It has its own hard problems: wallet ecosystem maturity, credential lifecycle management, adoption incentives, and the political challenge of getting other states and countries to recognize Utah's framework. Mayo's operational concerns about credential systems apply to SEDI too; they are not magically resolved by putting a legal framework around them.

But SEDI does not fit cleanly into any of Mayo's three buckets, and that is the point. It is better described as state-endorsed, rights-first digital identity reuse. SEDI keeps institutional authority where it belongs: the state still verifies identity, endorses credentials, and defines legal duties for participants. It moves presentation and consent closer to the individual: the person controls what they disclose, to whom, and under what terms. And it wraps the whole system in public-law governance: constitutional principles, a duty of loyalty, voluntary adoption, and enforceable accountability.

That is not "replacing" identity infrastructure. It is not "no central control" or "all power rests with the individual." It is an attempt to join cryptographic trust and legal trust into a public identity foundation. The state provides the endorsement and the legal framework; the individual provides the consent and controls the presentation; the technology provides the mechanism for doing both securely. As I explored in SEDI and Client-Side Identity, this resolves a problem that has plagued digital identity since the 1990s: people will not pay for identity proofing, but they already pay their state government for it without realizing it. SEDI routes around the economic bottleneck that killed client-side certificates.

Mayo's useful contribution is the question itself. But the answer for SEDI is none of the above. SEDI enhances institutional trust by giving it a legal and cryptographic expression that the individual controls. It does not duplicate infrastructure into unsupervised wallets. It does not replace institutional authority with self-sovereign cryptography. It creates a new kind of public trust infrastructure in which the institution, the individual, and the law each carry weight. Getting SEDI's category wrong makes it easy to dismiss. Getting it right means engaging with the harder, more interesting question: what does identity infrastructure look like when it starts from rights and relationships rather than from databases and documents?

Photo Credit: SEDI: None of the Above from ChatGPT (public domain)

Data Protection Missed the Point; Loyalty Gets It Right

Phil Windley // Wed Apr 29 22:54:00 2026 // sedi privacy identity gdpr myterms vrm relationships

I'm sitting in a session at IIW hosted by Sam Smith on the duty of loyalty. Sam made the point that duty of loyalty is fundamentally about the relationship, not the data—and that caught my attention because of my past work on framing identity as being more about relationships than attributes. I have long argued that we build identity systems to manage relationships, not identities.

If that is true, then the way we regulate those systems ought to focus on the relationships too. But most privacy regulation starts with the data instead. GDPR, CCPA, and their descendants define categories of personal information, prescribe what can be collected, require consent for processing, and mandate deletion on request. The regulatory object is the data itself—not the relationship that gives the data meaning. And for all their ambition, data protection regimes have done little besides annoy everyone with cookie consent dialogues; the surveillance business models they were supposed to curtail are doing just fine.

This data-centric focus is not accidental; it reflects a deeper assumption. GDPR and its descendants treat people as data subjects—consumers of services whose information is processed by a controller. The person has rights over their data, but no standing as an independent party in the relationship. They are subjects, not participants.

If you start from first person identity instead, where people have a unique digital existence and are not merely rows in someone else's database, then it's natural to see them as autonomous parties who enter relationships on their own terms. The duty of loyalty follows naturally from that framing.

In their 2022 paper "Legislating Data Loyalty," Hartzog and Richards make a similar argument. The real problem, they say, is not what happens to the data; it is what happens in the relationship between the person who trusts and the institution that holds power. They propose a duty of loyalty—borrowed from fiduciary law—that would prohibit organizations from processing data or designing systems in ways that conflict with the best interests of the people who trust them.

This shifts the focus from procedural compliance around data to substantive obligations within a relationship. The relationship provides the context for the interactions that happen within it; the duty of loyalty informs that context. As I explored in Are Transactional Relationships Enough?, our online relationships are almost all transactional, administered by platforms that make product decisions to monetize the interaction rather than serve the people in it. A duty of loyalty directly addresses that imbalance.

That is exactly what Utah's SEDI legislation does. The duty of loyalty provision in the statute places a fiduciary obligation on institutions that use or rely on a state-endorsed digital identity: they owe loyalty to the person whose identity they hold. This is not a data-handling rule. It is a relationship rule. It says that the institution is not free to use the identity relationship for its own benefit at the expense of the identity holder. As I wrote in A Legal Identity Foundation Isn't Optional, SEDI provides the legal base layer for first-person digital trust. The duty of loyalty is the provision that makes that base layer meaningful; it gives the identity holder standing not as a data subject but as a party in a relationship with enforceable expectations.

The shift matters because data-centric regulation has a structural weakness: it lets institutions comply with the letter of the law while still exploiting the relationship. You can minimize data collection, publish a privacy policy, and offer an opt-out button—and still design systems that manipulate, surveil, and extract value from the people who depend on them.

A duty of loyalty cuts through that. It asks whether the institution is acting in the interest of the person who trusted it, not whether it followed the right procedures with the right categories of data. Importantly, digital relationships are voluntarily entered into by both parties; the institution chooses to accept the identity credential, and the individual chooses to present it. That voluntary entry is what gives the duty of loyalty its legal and moral footing—both sides opted into the relationship, and so both sides are bound by its terms.

As I explored in MyTerms and SEDI's Duty of Loyalty, MyTerms gives this relationship-based obligation concrete, operational rails. Today, the terms governing our online interactions are 60-page contracts of adhesion that no one reads and no one negotiates—unilateral declarations by the institution, take it or leave it. These adhesion contracts are the inevitable product of regulating data rather than relationships; when the law only asks institutions to disclose what they do with data and obtain consent, a take-it-or-leave-it document is all that is required.

A duty of loyalty expressed through MyTerms replaces that with a bilateral contract. The individual's machine-readable terms define what loyalty looks like in a specific interaction; the institution agrees to those terms when it accepts the credential. Both parties hold a record of the agreement. The duty of loyalty gets teeth when there is a protocol for expressing and auditing what the individual expected. SEDI, operationalized through MyTerms, moves us from a world where institutions write the rules and people click "I agree" to one where both parties enter a relationship with mutual obligations and enforceable terms.

Photo Credit: Digital Relationships from ChatGPT (public domain)

MyTerms and SEDI's Duty of Loyalty

Phil Windley // Mon Apr 27 18:25:00 2026 // vrm myterms iiw privacy sedi identity

I'm at VRM Day before IIW, and the morning's primary topic is MyTerms, the newly published IEEE 7012 standard. MyTerms specifies a protocol for machine-readable personal privacy terms—terms that individuals proffer to websites and services, not the other way around. Both sides keep records of the agreement. The individual is the first party, rather than the second. That inversion matters more than it might seem at first glance; it is first person identity made operational in protocol.

What caught my attention is how naturally MyTerms connects to the duty of loyalty requirement in SEDI. The SEDI legislation places a fiduciary obligation on institutions that use or rely on a state-endorsed digital identity: they owe a duty of loyalty to the person whose identity they are using. That is a powerful legal principle, but it needs a mechanism. How does an individual express what loyalty looks like in a specific interaction? How does the institution know what it has agreed to? MyTerms can answer both questions. The individual's machine-readable terms define the boundaries of the relationship, and both parties hold a record of the agreement. The duty of loyalty gets teeth when there is a concrete, auditable expression of what the individual expected.

There may be details that need to shift to make this work cleanly—MyTerms was not designed with SEDI in mind, and SEDI's duty of loyalty was not written with a specific protocol in view. But the conceptual fit is striking. SEDI provides the legal foundation that gives people standing as first parties; MyTerms gives those first parties a language for saying what they want. One without the other is incomplete. Together, they start to look like the infrastructure for digital relationships where people are not merely data subjects but participants with enforceable expectations.

Photo Credit: MyTerms Exchange from DALL-E (public domain)

Building a Conversational Interface for Manifold with MCP and Picos

Phil Windley // Wed Apr 22 11:14:00 2026 // picos mcp conversational+interfaces manifold byu ai llm

Every winter semester, I like to sponsor a capstone project for BYU computer science seniors. This year, I worked with five students—Micaela Madariaga, Braydon Lowe, Chance Carr, Charles Butler, and Jayden Hacking—on a project I had been thinking about for a while: building a conversational interface for Manifold. Manifold is a platform built on the pico engine that enables the creation and orchestration of pico-based systems.

Manifold started as a system for putting QR codes—what we call tags—on physical things like your bag, your bike, or even a dog. We called it SquareTag. Each tagged thing gets a pico that stores owner information and can be scanned by anyone who finds it. Over time, we added the ability to install other skills on thing picos, extending what they can do. We even built a connected car platform called Fuse on the same architecture, where each vehicle is a pico with rulesets for tracking fuel usage, maintenance, and trips. Manifold is the general-purpose platform for creating and managing these pico-based systems.

Manifold is powerful, but like any GUI, there are a number of concepts that users have to learn before they can do anything useful. I wanted to know whether a conversational interface could let people interact with Manifold with less friction. The answer turned out to be yes. The team was able to create a usable conversational interface for Manifold that exposes the primary features and makes it easy to use. The interesting part is the architecture that provides a Model Context Protocol (MCP) interface to a constellation of picos and the APIs they expose. That combination separates concerns in a way that gives you a conversational layer without sacrificing the structure and reliability of the underlying system.

Manifold and the Expert Barrier

Manifold gives each user a collection of digital representations of physical things. Each of these is represented by a picos. Each thing in Manifold can have tags for physical identification, journal entries for notes, and owner information for recovery. The GUI presents these as a grid of cards, each showing the thing's name, its tags, and recent journal entries:

This works if you already understand the system. You can see that the Delsey carry-on has a SquareTag attached, that the furnace has journal entries tracking filter changes, and that each thing has its own set of installed skills. But creating a new thing, assigning a tag, or adding a journal entry requires navigating through multiple screens and understanding concepts like skills, communities, and tag domains. For someone encountering Manifold for the first time, the GUI is a wall of concepts that have to be learned before anything useful can happen.

That is the gap we wanted to bridge. Instead of requiring users to learn the GUI's mental model, we wanted to let them say "create a thing called Running Shoes" or "add a note to the toy car" and have the system figure out the rest. The question was whether we could build that conversational layer without losing the structure and reliability that makes Manifold useful in the first place.

What Conversational Interfaces Are Really About

The wall-of-concepts problem I just described is not unique to Manifold. It is the fundamental problem with GUIs. Every GUI requires users to learn its particular model of the world before they can accomplish anything: which menu holds the operation they want, what the icons mean, how the screens connect to each other, what has to happen in what order. We have spent decades building GUIs and we have gotten good at it, but the core limitation remains. The user has to learn the tool's language rather than the tool learning theirs.

I think GUIs are dead—at least for most user experiences. Conversational interfaces are not a convenience layer on top of a GUI; they are a replacement for it. A conversational interface is a translation layer between human intent and system behavior. The user says "create a backpack" and the system figures out the rest. The user does not need to know about skills, communities, tag domains, or which screen to navigate to. They just say what they want. The system's capabilities can be discovered and exercised through dialogue rather than through a visual hierarchy that someone had to design and someone else has to learn. Better still, a conversational interface can explain what it is doing and why, teaching users about the system as they use it.

The Architecture

The capstone team designed a pipeline architecture that has six components. The diagram shows what the team built (the green boundary) and the two external services it connects. The code is on GitHub.

• Chat UI (1) — A React frontend that handles user interaction and displays responses. It connects to the MCP Client via Socket.io for real-time status updates during tool execution.
• MCP Client (2) — The central coordinator. It receives user messages from the Chat UI, packages them with available tool definitions, and sends them to the LLM. When the LLM returns a tool-call instruction, the MCP Client routes it to the MCP Server for execution.
• LLM (3a) — Claude, accessed via Amazon Bedrock. This sits outside the team's code. It examines the available tools, interprets the user's intent, and returns structured JSON instructions specifying which tool to call and with what arguments.
• MCP Server (3b) — Exposes system capabilities as callable tools with JSON Schema definitions. Each tool maps to a specific KRL operation. The server communicates with the client over stdio, a standard MCP transport that keeps things simple.
• Manifold API Wrappers (4) — Translates MCP tool calls into HTTP requests to the pico engine, using a uniform JSON envelope for both raising events and making queries to the right pico.
• Pico Engine (5) — Also outside the team's code. It supports the execution of KRL rules and functions inside the pico constellation representing the owner's things. This is where the actual work happens.

Each component in this architecture does one thing. The LLM handles intent and language. MCP structures that intent into well-defined tool calls. The API wrappers translate those calls into pico engine operations. The pico engine executes them reliably. No single component needs to understand the full stack, and the team's code is cleanly bounded between the two services it connects.

How a Request Flows Through the System

Consider what happens when a user types "create a backpack" into the chat interface. The diagram shows the full request lifecycle:

The user's prompt goes to the LLM, which reasons about the intent and determines that it needs to call a tool. MCP translates that into a structured tool call—in this case, manifold_create_thing with the argument name: "Backpack". The tool call hits the Manifold API wrappers, which send the appropriate request to the pico engine. The engine returns structured JSON, which flows back to the LLM. The LLM converts the result into natural language and generates a response for the user. Notice that the LLM appears twice: first to understand intent and select a tool, then to convert the structured result into a human-readable reply.

The round trip takes a few seconds. From the user's perspective, they asked for a backpack and got one. From the system's perspective, the engine executed a rule inside the right pico with the right attributes, validated at every layer. Both views are accurate; the architecture just makes them compatible.

The Uniform Envelope

One design decision worth highlighting is the uniform JSON envelope the team created for all pico engine calls. Picos support two kinds of operations: queries (read state) and events (change state). Rather than handling these differently throughout the stack, the team built an adapter that normalizes both into a single request/response shape. Note the eci field in the envelope: that is the Event Channel Identifier, which identifies the specific pico representing the thing that the operation is being performed on.

// Request envelope
{
  "id": "correlation-id",
  "target": { "eci": "ECI_HERE" },
  "op": {
    "kind": "query",          // or "event"
    "rid": "io.picolabs.manifold_pico",
    "name": "getThings"
  },
  "args": {}
}

// Response envelope
{
  "id": "correlation-id",
  "ok": true,
  "data": { ... },
  "meta": {
    "kind": "query",
    "eci": "ECI_HERE",
    "httpStatus": 200
  }
}

This is a small thing that makes a big difference. Every tool in the MCP server returns a response with the same shape. Error handling follows the same pattern regardless of whether the underlying operation was a query or an event. The LLM sees consistent results, which makes its responses more predictable. Uniformity at this layer reduces complexity everywhere above it.

Skill Gating

One of the distinctive features of picos is that new functionality can be installed at runtime by adding KRL rulesets. Every Manifold pico comes with the safeandmine ruleset installed by default, which handles tagging and owner information. Other rulesets, like journal for notes, are installed on demand. Each ruleset brings its own API—new events it can handle, new queries it can answer. This is powerful, but it makes building a conversational interface harder because the set of available operations is not fixed. It changes per pico, and it can change during a conversation.

The team handled this by building a skill-gating system that dynamically controls which MCP tools the LLM can see, based on the rulesets installed on the current pico. If a pico does not have the journal ruleset installed, the LLM never sees the addNote or getNote tools. This prevents the LLM from attempting operations that would fail, and it creates a natural conversational flow around capability discovery. If a user asks to add a note to a pico that lacks the journal skill, the system explains what is missing and asks permission to install it. The interaction feels natural because the architecture supports it; the LLM is not guessing about what is possible.

Prompt Engineering as Interface Design

The team went through multiple iterations of their system prompt before arriving at something that worked well. As they describe in their prompt design document, the prompt is not just instruction text; it is a control surface for live conversational behavior. It constrains response length to 1-3 sentences for demo readability. It enforces skill-gating in the prompt itself, not just in code, so the LLM explains missing prerequisites and asks permission before installing new capabilities. It tracks a "last used thing" so users can say "tag it" or "rename that" without repeating themselves. It requires explicit confirmation before destructive actions like deleting a pico—a trust pattern as much as a safety pattern, demonstrating that the system can act powerfully but only after checking intent.

These are interface design decisions expressed in natural language rather than code. The team documented their rationale carefully: earlier versions produced responses that were too long, attempted skill-dependent actions without checking installed skills first, and drifted into heavy Markdown formatting that looked out of place in a minimal chat UI. Each iteration tightened the prompt based on observed failures. This iterative approach to prompt engineering mirrors how good interface design works generally. You watch people use it, see where it breaks, and fix the interaction, not just the code.

What Worked and What Didn't

The core architecture works well. A user can create, rename, and delete digital things; organize them into communities; assign physical tags; and add journal notes—all through natural conversation. The layered design means each component can be tested and reasoned about independently. The MCP server has a clean test suite. The uniform envelope makes debugging straightforward because every response has the same shape.

The hardest part, according to the team's lessons learned document, was building the API wrappers. The pico engine endpoints were easy to identify through browser network monitoring, but getting the POST request requirements right and bridging the gap between natural language and the API's expected data formats took significant effort. Debugging was also difficult because the LLM's error messages were vague; the team had to use a separate MCP Inspector to diagnose problems at the tool layer.

LLM hallucination was an ongoing challenge. After hundreds of similar create, edit, and delete operations accumulated in the conversation context, the model's accuracy degraded. The team identified context management—flushing old interactions and keeping the context window focused—as a key area for improvement. They also noted that local testing came late in the development process; earlier access to a local environment would have reduced the noise in the shared context.

What This Means

This project demonstrates something I have believed for a long time: the best technology emerges from solving real problems iteratively rather than from grand design. The students did not start with a theory about conversational interfaces. They started with a concrete problem—Manifold is hard to use if you do not already know how it works—and built their way to a solution that has broader implications.

The combination of MCP and picos is particularly compelling because it plays to the strengths of each component. MCP gives the LLM a structured way to interact with external systems; the model does not need to generate raw API calls or guess at endpoint formats. Picos provide a decentralized, event-driven runtime where each entity maintains its own state and communicates via events. The LLM does not need to understand that architecture. It just needs to know which tools are available and what arguments they take. MCP handles the rest.

The biggest open question is portability. Right now, the system requires hand-written API wrappers for each set of pico engine operations. One of the capstone judges suggested that a more portable approach would generate the necessary tool definitions and wrapper functions from a provided set of API specifications. That would let you point this architecture at any service, not just Manifold. I think that is exactly the right next step, and it is the kind of insight that comes from building something real and showing it to smart people.

I have been building pico-based systems for nearly two decades, and they remain the most interesting technology I have worked on. I've been teaching students at BYU for even longer. This project brought those two things together in a way that was genuinely fun. Micaela, Braydon, Chance, Charles, and Jayden took a system I care about deeply and made it more accessible by building something I had dreamed of creating. That is what working with students does: they see possibilities you have stopped looking for because you are too close to the problem. I am grateful for their work and excited to see where it leads.

Photo Credit: Manifold tag from Manifold (used with permission)

It's Not Just What Agents Can Do...It's When They Can Do It!

Phil Windley // Fri Mar 27 13:59:00 2026 // agentic+ai ai authz authorization identity

This post is part of a series on using dynamic authorization to control and coordinate AI agents. See the series recap to find other posts in this series.

Suppose you ask an agent to summarize a set of documents and then email the summary to a group. You might be comfortable granting the agent access to your email for that purpose, but only after the summary has been completed and reviewed. If the agent can access your email too early, sensitive information from your inbox could leak into the task. In agent systems, authorization is not only about what actions are permitted. It is also about when they are permitted.

That makes sequencing an authorization problem, not just a workflow problem. Agents do not simply perform isolated actions. They execute plans, accumulate context, revise their strategies, and sometimes coordinate with other agents or people. A permission that is safe at one point in a task may be unsafe at another. The challenge is to ensure that authority unfolds in the right order and only under the right conditions.

Why sequencing matters

Traditional authorization systems are good at answering questions like "Can this principal read this file?" or "Can this service call this API?" Agent systems introduce a different question: "Can this principal take this action now, given what has already happened?" In other words, authorization must constrain the path, not just the destination.

Consider a few examples:

• An agent migrating records between systems needs to verify the backup completed successfully before it begins deleting records from the source. If it starts deleting before the backup is confirmed, data loss is irreversible.
• A research agent gathering information from multiple sources needs to finish collecting and cross-referencing before it synthesizes a summary. Starting the summary too early means drawing conclusions from incomplete data and then anchoring on them.
• A deployment agent rolling out a new service version needs to confirm the canary deployment is healthy before it proceeds to full rollout. Granting it permission for the full rollout from the start means a bad canary could cascade.
• A triage agent classifies incoming support tickets and routes them to specialized agents. The specialized agent should not begin work until triage is complete and the right context is attached. Acting on incomplete classification means acting on wrong information.
• A code review agent runs a test suite against a proposed change. It needs to finish the tests before posting a review summary. A partial summary while tests are still running could greenlight a broken build.
• An agent gathers invoices and calculates reimbursement totals. It should not initiate payment until a manager approves the request.
• An incident response agent collects logs and diagnoses the problem, but restarting production systems requires an engineer to sign off on the plan.

In each case, the question is not whether the action is allowed in the abstract. It is whether the action is allowed at this point in the workflow and under these conditions.

Sequencing through policy

One way to handle sequencing is through policy. In this model, the authorization request includes contextual attributes that represent the task's current state, allowing policy to determine whether the next action is permitted. Consider the data migration example: an agent should not delete source records until the backup is confirmed. Here's a pseudocode policy that enforces that:

permit delete_source_records
when backup_status == "verified";

This approach works well for recurring workflows and institutional rules. Because the sequencing logic lives in policy rather than in agent behavior, operators can inspect and update it independently. In effect, the system says: these actions are forbidden until the required conditions are met.

Sequencing through delegation data

Another approach is to model sequencing as evolving delegated authority. Instead of encoding every possible sequence in durable policy, the system issues task-specific authority at each stage. The agent starts with a limited capability set, and additional permissions become available only when the prior stage has completed successfully. In this model, authority changes as the task progresses.

Consider a deployment agent rolling out a new service version. The agent initially receives a capability token scoped to the canary environment. Only after the canary passes health checks does the monitoring system issue a new token authorizing full rollout. A policy evaluates delegation data like this:

permit full_rollout
when delegation.type == "canary_passed"
  && delegation.service == request.service
  && delegation.version == request.version;

This is especially useful for one-off or highly contextual tasks. Every deployment targets a different service and version; writing a durable policy for each one would be impractical. The delegation data carries the specifics while the policy enforces the pattern.

In this sense, sequencing can be handled either as policy as code or as policy as data. Durable institutional workflows are often best expressed in policy. Temporary, task-specific sequencing can often be handled through delegation data evaluated by policy at runtime.

Adding multi-signature approval

Sequencing alone is not enough. Some workflows also require multi-signature approval: a human or another trusted actor explicitly authorizes the next step before the agent can proceed.

Consider a financial reimbursement agent. The agent might gather receipts and produce a reimbursement summary, but it should not initiate payment until a manager approves the request. Or consider an incident response agent that identifies a remediation plan but cannot execute it until an SRE signs off. In these cases, the authorized trajectory includes both ordered steps and approval conditions. This can also be expressed through policy:

permit reimbursement_pay
when summary_status == "complete"
  && approvals.contains("manager_approved");

Or it can be modeled through delegation data, where the approving party issues a credential or capability indicating that the next stage is authorized. Authority is not granted all at once; it unfolds over time and across actors.

Hybrid models

In practice, most real systems will combine these approaches. High-level sequencing rules may be defined in policy, while task-specific permissions are carried in delegation records or approval credentials. A workflow might require that every payment be approved by policy, but use task-specific delegation data to determine which specific invoice, amount, and recipient are in scope.

This is another example of why the distinction between policy as code and policy as data matters. They are not competing ideas. They are complementary tools for shaping how authority is granted, constrained, and evolved in dynamic systems.

Authorized trajectories

Agents do not just need authorization boundaries. They need authorized trajectories. We need to govern not only the actions an agent may take, but the order in which it may take them and the approvals required along the way.

As agents become more capable, safety will depend less on static permission sets and more on our ability to shape how authority unfolds over time. This is not a narrow technical point. The people whose data, money, and reputations are at stake deserve systems where authority is earned step by step, not handed over in bulk. Governing the path an agent takes is how we keep humans in control of the systems that act on their behalf.

Photo Credit: Sequencing agents from ChatGPT (public domain)

Agentic AI and Dynamic Authorization: A Series Recap

Phil Windley // Thu Mar 19 11:05:00 2026 // agentic+ai authz authorization ai identity

Over the past few months, I've been exploring a central question in agentic AI: how autonomous systems can be useful without becoming ungovernable. Taken together, these essays trace a progression from the basic insight that authorization is the hard problem, through practical patterns for putting policy inside the agent loop, shaping plans with constraints, governing actions with externalized policy, and finally thinking about delegation both within and across domains.

• Why Authorization Is the Hard Problem in Agentic AI — This post lays the foundation for the whole series by arguing that static authorization breaks down in agentic systems. Agents act over time, under changing conditions, so authorization has to become dynamic, continuous, and policy-based, guiding behavior step by step rather than simply approving or denying a request once.
• A Policy-Aware Agent Loop with Cedar and OpenClaw — This post moves authorization into the heart of the agent loop itself. Instead of treating access control as a one-time check, it shows how a Cedar-backed decision point can continuously evaluate tool use and feed results back into replanning, making authorization part of the agent's ongoing reasoning.
• Beyond Denial: Using Policy Constraints to Guide OpenClaw Planning — Traditional authorization often acts as a gate that says "no" after an agent has already decided what to do. This essay explores a better pattern: giving the agent policy constraints up front so it can plan within allowed boundaries while still having every concrete action enforced at runtime.
• Childproofing the Control Plane: Using Cedar to Build Frontal Lobes for Agentic Systems — Connecting an agent to real systems like Home Assistant makes the value of agentic AI obvious, but it also makes the risks obvious. This post explains how externalized, deterministic Cedar policies can provide the governance layer that keeps an agent useful while preventing it from crossing safety, security, and privacy boundaries.
• Delegation as Data: Applying Cedar Policies to OpenClaw Subagents — Here I show how delegation inside a single domain can be modeled as data rather than hard-coded logic. In the OpenClaw and Cedar demo, a stable policy set evaluates dynamic delegation records so subagents can be given narrowly scoped authority without expanding the overall trust boundary.
• Cross-Domain Delegation in a Society of Agents — This post argues that cross-domain delegation is about more than handing one agent a credential. For delegation to work across organizational boundaries, agents need policy-defined limits, promises that communicate intended behavior, and reputation that creates trust over time.
• It's Not Just What Agents Can Do...It's When They Can Do It! — This post explores sequencing as an authorization problem. Agents execute plans where the safety of each step depends on what has already happened, so authorization must constrain the path, not just the destination. It shows how policy, delegation data, and multi-signature approval can govern the order in which agents receive authority.
• The Shape of Context in Agentic Authorization — This post looks at the hardest part of the PARC model in agentic systems: context. It argues that authorization signals multiply, travel through a mesh of agents with different audiences at each hop, and must reconstruct accountability at request time in a non-directed world. Even as the volume of context grows, the decision about what is allowed should stay deterministic and inspectable rather than handed to a model.

What ties these posts together is the idea that agentic AI needs governance that is as dynamic as the agents themselves. If we want agents that can plan, delegate, and act in the real world, then policy has to move from the edge of the system into its core, shaping behavior continuously and making autonomy governable rather than merely powerful.

Photo Credit: Agents at Our Service from ChatGPT (public domain)