Product Decisions This Supports
- Pilot vs. demo readiness. This release is the evidence needed to move from "we think agent execution is safe to show" to "we can put it in front of a design partner's data." The audit removed every T1–T15 mitigation one at a time and recorded the failure: session isolation, tool delegation, workspace containment, budget limits, and run locking are now asserted rather than described in a docblock. That is the specific artifact a security review or a customer's vendor questionnaire asks for.
- Build vs. buy on agent orchestration. The package now owns the genuinely hard, low-glamour parts of a multi-actor agent runtime: per-actor session keys, grant-minus-deny ability intersection across agent delegation, symlink containment on tool writes, concurrent run locking against a shared database, and limit attribution. If our roadmap has a multi-tenant agent surface in it, this collapses a large and risky build.
- Roadmap gate for beta/GA. The work in v0.1.3–v0.1.4 was reliability, not features: two live security fixes, a provider health write that could fail a run under contention, a
RunLock lease that could be deleted with all 22 serial tests green, and a wall-clock deadline with no test at all. If a beta milestone is gated on "runtime correctness," this clears it. The remaining gap is operational — alerting and dashboards on budget breaches and provider health — not more control work.
- Permission and approval UX. The delegation deny-path finding is a product story, not just a test story: an operator who revokes a tool by name could previously have that tool reach a child agent and execute. "Revocation is real" is a shippable promise to security-conscious buyers, and it justifies investment in a proper permissions/approval surface rather than a config file.
- Admin surface direction. The architectural test that every class in
src/UI/Livewire/ authorizes somewhere means new control-center pages cannot be added ungated. If we adopt the Livewire UI as our admin surface, our review burden per new page drops and we inherit that guarantee for free.
- Where to spend the next quarter. Five gated pages — including run detail views that expose prompts, webhook secrets and full execution traces — could have lost their gate with the whole suite green. That argues for continued investment in negative-path and deny-path testing as a standing practice, not a one-off audit, and for treating "tests that fail when the control is deleted" as a release criterion we ask of every dependency.
When to Consider This Package
Adopt when:
- We are building multi-actor AI execution in Laravel — human users alongside automations and agents — and need real per-actor session boundaries, including the collision case where an automation labelled with a user's primary key differs only by actor type.
- We need tool/ability delegation with explicit deny semantics, where a parent's revoked tool must not be re-granted through a child's intersection.
- Tools write files, and we need containment that survives symlinked leaves and symlinked directories as distinct threats.
- We enforce budgets (tokens, wall clock, and others) and need to know which limit tripped, since
RunState::TimedOut is where every breach lands.
- We run more than one worker against one database and need run ownership that actually holds under collision.
Look elsewhere when:
- The deployment is single-process or single-tenant. The concurrency harness starts real OS processes against a barrier, deliberately avoids
pest --parallel, and collides with the shared-schema optimisation in TestCase. That is real test-suite cost for a control we would not need.
- The stack is not Laravel. The value here is concentrated in Livewire authorization, Eloquent-backed leases, and queue semantics.
- We need a vendor to carry the residual security risk. This is a v0.1.x package whose own audit produced live security fixes in v0.1.3 and a concurrency fix here; adopting it means we own the next finding.
- We need a stable public API. Pre-1.0, internals are actively being hardened and reorganised, and the release notes show classes and call sites still moving.
- We need concurrency guarantees on a database other than the one the lease was proven against. The audit proved the control exists; it did not prove portability.
Caveat to carry into the decision: anything deployed before v0.1.4 carried real defects — five pages that could lose their authorization gate with a green suite, a run-failing race in provider health writes, and an unenforced wall-clock deadline. Existing deployments should upgrade before any external exposure, not as routine hygiene.
How to Pitch It (Stakeholders)
For executives. "We can now demonstrate, with tests that fail if the control is removed, that revoked permissions stay revoked, that one actor's session cannot bleed into another's, that a file-writing tool cannot escape its workspace, and that a run's budget actually stops it. That is the difference between a demo and something we can pilot with a customer. It is unglamorous work — the last two releases shipped two security fixes and one concurrency fix — but it is the work that removes the blocker. The package is still pre-1.0, so we go in eyes open: we would own the residual risk and the upgrade path."
For engineering. "The authors ran a removal audit across every threat mitigation: delete the control, confirm the suite goes red, record it. It found that RunLock's database lease — the class's documented authority — could be deleted with 22 serial lock tests green, so they built a barrier-synchronised multi-process harness and proved it under real collision. It found Run::hasExceededDeadline() had one call site and no test. It found the deny half of delegation was never exercised, so a child could receive a tool the parent was explicitly denied and execute it. All fixed, all now asserted, with the architectural test preventing a nineteenth ungated Livewire page. The costs are real: heavier tests, no pest --parallel compatibility, and pre-1.0 churn. The payoff is that every guarantee we would build on top of this now has a test that names it."