Skip to content

Conversation

@sayakmaity
Copy link

Summary

Fixes the authorization bypass bug that caused 403 Forbidden errors when users tried to view agent-created tasks from the SGP UI.

Root Cause: When agents create tasks via ACP, authorization_service._bypass() was returning True because agent_identity is set. This caused grant() to skip creating permission records, so users couldn't access those tasks later even with proper role-based access.

The Fix: Split the bypass logic into two methods:

  • _bypass_check(): Used for check() and list_resources() - bypasses when agent_identity is set OR authorization is disabled (preserves existing agent-to-agent trust behavior)
  • _bypass_write(): Used for grant() and revoke() - only bypasses when authorization is disabled, NOT when agent_identity is set (ensures permission records are always created)

Evidence

From SGP staging logs, multiple 403 errors for task f46e8192-2cca-415c-95e3-27f5867ea418:

[authorization_service] Checking read permission on task:f46e8192-2cca-415c-95e3-27f5867ea418
GET /tasks/f46e8192-2cca-415c-95e3-27f5867ea418 HTTP/1.1" 403 Forbidden

Infrastructure was healthy (RDS CPU 8-9%, replica lag 15-25ms, Redis 1% CPU) - confirming this is an application-level bug, not infrastructure.

Test plan

  • Unit tests pass
  • Integration tests pass
  • Manual testing: Create a task via agent, then verify user can access it from SGP UI
  • Verify existing agent-to-agent communication still works (check operations should still be bypassed)

Related

  • Slack thread about delayed/broken Agentex traces in SGP staging
  • Account: 6939c7450f636b79305ab5ce ([Demo] Financial Services)

When agents create tasks via ACP, the authorization service was
incorrectly bypassing the grant() operation due to _bypass() returning
True when agent_identity is set. This caused permission records to not
be created, resulting in 403 Forbidden errors when users tried to view
agent-created tasks from the SGP UI.

This fix splits the bypass logic into two methods:
- _bypass_check(): Used for check() and list_resources() - bypasses
  when agent_identity is set OR authorization is disabled (preserves
  existing agent-to-agent trust behavior)
- _bypass_write(): Used for grant() and revoke() - only bypasses when
  authorization is disabled, NOT when agent_identity is set (ensures
  permission records are always created)

Root cause: Tasks created by agents had no permission records, so when
users accessed them via the UI, the permission check failed even though
the user had role-based access to the account.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants