You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(authz): register agentex resources and grant agent/task ownership (#270)
## Related work
Parent ticket: AGX1-242 - AgentEx authorization dual-write.
This change is part of a 4-PR stack across 3 repos.
| Repo | PR | Purpose |
|---|---|---|
| scaleapi/scaleapi |
[scaleapi/scaleapi#146335](scaleapi/scaleapi#146335)
| merged flag registry update for the shared AgentEx resources rollout
flags |
| scaleapi/agentex |
[scaleapi/agentex#364](scaleapi/agentex#364) |
agentex-auth routes each auth verb to one backend target |
| **scaleapi/scale-agentex** | **this PR** | **registers agentex
resources in the authorization graph and grants agent/task ownership** |
| scaleapi/scale-agentex |
[#271](#271)
| denied direct agent access collapses to 404 |
**Merge/deploy order:**
[scaleapi/scaleapi#146335](scaleapi/scaleapi#146335)
is merged; deploy
[scaleapi/agentex#364](scaleapi/agentex#364)
before this PR, then merge/deploy
[#271](#271).
Rollout per account is: enable `fgac-agentex-resources-dual-write`,
backfill existing resources into Spark, then enable
`fgac-agentex-resources` reads.
## What
Registers agentex resources in the authorization graph on create and
removes them on delete, separating resource lifecycle from explicit
ownership:
- **Agents and tasks** register in the authorization graph on create and
record an explicit owner; on delete they deregister and the owner record
is revoked.
- **Schedules and agent API keys** register under their parent agent on
create and deregister on delete. Permissions cascade from the parent
agent, so no separate owner record is written.
Registration runs before the resource is persisted, so an authorization
failure fails closed with no orphaned row. If the persist (or the
Temporal create, for schedules) later fails, a compensating deregister
runs.
## Why
Giving each verb a single backend keeps the existing ownership writes
(`grant`/`revoke`) unchanged and confines the new behavior to the new
lifecycle interface (`register`/`deregister`). Explicit ownership is
recorded only for agents and tasks; schedules and agent API keys inherit
access from their parent agent, so they need no owner record of their
own. Issuing the two write kinds independently keeps both backends
current, so reads can cut over per account with a clean rollback.
## Testing
- Unit and integration tests covering the agent, task, schedule, and
api_key authorization writes (register/deregister ordering,
fail-closed-before-persist, and compensating cleanup).
- `ruff check` / `ruff format`.
0 commit comments