Blog
Writing on agent permission infrastructure.
Enforcement models, decision boundaries, passport design, and the real cost of fail-open integrations.
The decision packet: BehalfID's verification primitive
Every verify call produces a decision packet — a structured answer to one question: is this specific action allowed right now? Here's what happens between the request and the response.
Fail closed: the only safe default for agent enforcement
When an agent doesn't have permission, two things can happen: it stops, or it doesn't. One of those is safe. The gap between availability and enforcement is where most agent incidents happen.
Why AI agents need permission passports, not API keys
API keys tell you who is calling. They don't tell you what that caller is allowed to do in this moment, for this action, against this resource. For autonomous agents, that distinction matters.
Connected agents vs native agents: choosing the right integration model
BehalfID supports two agent models. Native agents are custom integrations you build and control. Connected agents represent external tools — ChatGPT, Claude, Zapier — that you don't control at the protocol level. The distinction changes what enforcement looks like.
Webhooks as an audit layer: signed events for agent observability
The verify response tells your integration what was decided. Webhooks tell everything else — your SIEM, your alerting system, your audit database — asynchronously and in real time. Here's how BehalfID's outbox-backed delivery model works.
Requires approval: when agents should pause before acting
Not every action is a binary allow-or-deny. Some actions are within scope but high enough risk that a human should review before the agent proceeds. That's what requiresApproval is for — and wiring it correctly is different from wiring a denial.