Summary
Autonomous agents like OpenClaw operate with broad, static permissions — regardless of whether they’re handling a trivial status check or a production remediation.
This proposal outlines a PoC for Task-Based Access Control (TBAC) — a dynamic authorization model where agent permissions are scoped to the specific task being executed, time-bound, resource-constrained, and auditable across delegation chains.
The PoC layers TBAC/IBAC on top of existing sandbox isolation (NemoClaw/OpenShell), integrates AGNTCY Identity for trust anchoring and TBAC, and demonstrates how policy engines like OpenFGA and ibac.dev can provide dynamic, intent-aware authorization. The goal is to build a reference architecture and white paper for securing externally-triggered autonomous agents.
Authorization Gap in Autonomous Agents
OpenClaw agents today are effectively single-tenant in terms of authorization. While there has been some work toward multi-tenancy, there is no strong authorization model for individual sub-agents or dynamically composed agents.
NemoClaw with OpenShell solves runtime isolation well. OpenShell enforces what an agent can do at the kernel and environment level — filesystem, syscalls, network, and declarative policy boundaries.
The unsolved problem is authorization granularity and strong trust model for how agents are introduced into communication channels or collaborative environments.
Today, an OpenClaw agent’s permissions are defined once at sandbox creation and remain static for the life of the sandbox. The agent has the same access whether it’s:
• Responding to a casual Slack question
• Generating a report using multiple tools and data sources
• Processing a webhook to to perform a scoped task
These are fundamentally different trust contexts, but the agent operates with identical permissions.
For example, there is no mechanism to express:
“For this specific task, triggered by this specific event, you may read observability metrics for 5 minutes and post to a channel — but you may NOT mutate infrastructure without approval.”
Task-Based Access Control (TBAC) as a potential solution for autonomous agent authorization gap
TBAC (Task-Based Access Control) is dynamic authorization models in which permissions are scoped to the agent’s current task or declared intent, rather than statically assigned via identity or role.
• RBAC: Agent receives permissions based on an assigned role — static permission boundaries
• ABAC: Access is determined by evaluation of identity and resource attributes
• TBAC: Permissions are derived from the contextual specifics of the active task (what is being done, why, and triggered by what)
• IBAC: Permissions are granted based on the stated or inferred intent of the action, enabling even finer-grained and context-sensitive access
In TBAC/IBAC models, identities and roles remain important, but the set of allowed operations is evaluated at execution time, considering task and intent data as inputs to the authorization decision.
Key properties of TBAC/IBAC:
1. Task/Intent-Scoped — Permissions are explicitly bound to an individual action, task, or agent intent
2. Time-Bound — Each authorization is short-lived, tightly tied to the lifespan of the relevant task/intent
3. Resource-Constrained — Permissions narrowly target only what is necessary for that task/intent
4. Trigger-/Intent-Aware — Authorization logic considers both how (and why) an action was initiated and what the agent intends to achieve
5. Delegation-Safe — When agents delegate or collaborate, their effective permission scope only shrinks (never broadens) through each handoff
6. Externally Enforced — All decisions, constraints, and audit logs are handled in an external, policy-driven engine—never just inside agent code or process
Existing Authorization Patterns Fail for Autonomous Agents
OAuth 2.0 assumes a human-driven request-response model. Autonomous agents break that assumption:
• Triggered by machine events (alerts, webhooks, schedules)
• Operate without human session context
• Delegate tasks across multiple agents
• Require different permissions per execution
Why Existing Patterns Fail
Service Accounts
No human traceability, no task context — all executions look identical.
Impersonation
Grants full user permissions — violates least privilege.
On-Behalf-Of (RFC 8693)
Assumes a human-originated request and linear delegation. Agent systems are event-driven and branching.
OAuth is necessary, but insufficient. TBAC adds a task-aware authorization layer above token systems.
Trust Model for Autonomous Agents
TBAC requires a trust anchor to verify agent identity before granting permissions.
AGNTCY Identity provides:
• Verifiable agent identity (Agent Badges)
• Capability metadata
• Issuer traceability (org/human accountability)
The TBAC engine uses identity as a gate, not the decision itself.
Proposed PoC Scope
Phase 1: TBAC/IBAC Mapping & Agntcy Integration
- Define TBAC and IBAC requirements
- Survey existing policy engines (e.g., Cedar, OPA/Rego, OpenFGA)
- Map requirements and identify implementation gaps
- Evaluate policy expression for task/intent contexts
- Design scoped token model including Agntcy Identity integration
- Set standards for decision logging and auditability
- Document tool fit, gaps, and extension needs
Phase 2: Identity Integration
- Integrate AGNTCY Identity system
- Implement Agent Badge verification mechanisms
Phase 3: Tooling Enhancements
- Add support for token-aware MCP tools (e.g., Slack, GitHub)
- Include provenance metadata within exchanged messages
Phase 4: Delegation & Auditing
- Enable end-to-end delegation tracking
- Enforce scope narrowing across delegated actions
- Provide audit visualization tools and dashboards
Deliverables
- Prototype of a TBAC/IBAC-aware policy engine
- Comprehensive gap analysis report evaluating TBAC/IBAC tool support
- Docker Compose stack for local deployment
- Curated policy library
- Reference architecture documentation
- Technical white paper outlining design and lessons learned
References
Summary
Autonomous agents like OpenClaw operate with broad, static permissions — regardless of whether they’re handling a trivial status check or a production remediation.
This proposal outlines a PoC for Task-Based Access Control (TBAC) — a dynamic authorization model where agent permissions are scoped to the specific task being executed, time-bound, resource-constrained, and auditable across delegation chains.
The PoC layers TBAC/IBAC on top of existing sandbox isolation (NemoClaw/OpenShell), integrates AGNTCY Identity for trust anchoring and TBAC, and demonstrates how policy engines like OpenFGA and ibac.dev can provide dynamic, intent-aware authorization. The goal is to build a reference architecture and white paper for securing externally-triggered autonomous agents.
Authorization Gap in Autonomous Agents
OpenClaw agents today are effectively single-tenant in terms of authorization. While there has been some work toward multi-tenancy, there is no strong authorization model for individual sub-agents or dynamically composed agents.
NemoClaw with OpenShell solves runtime isolation well. OpenShell enforces what an agent can do at the kernel and environment level — filesystem, syscalls, network, and declarative policy boundaries.
The unsolved problem is authorization granularity and strong trust model for how agents are introduced into communication channels or collaborative environments.
Today, an OpenClaw agent’s permissions are defined once at sandbox creation and remain static for the life of the sandbox. The agent has the same access whether it’s:
• Responding to a casual Slack question
• Generating a report using multiple tools and data sources
• Processing a webhook to to perform a scoped task
These are fundamentally different trust contexts, but the agent operates with identical permissions.
For example, there is no mechanism to express:
“For this specific task, triggered by this specific event, you may read observability metrics for 5 minutes and post to a channel — but you may NOT mutate infrastructure without approval.”
Task-Based Access Control (TBAC) as a potential solution for autonomous agent authorization gap
TBAC (Task-Based Access Control) is dynamic authorization models in which permissions are scoped to the agent’s current task or declared intent, rather than statically assigned via identity or role.
In TBAC/IBAC models, identities and roles remain important, but the set of allowed operations is evaluated at execution time, considering task and intent data as inputs to the authorization decision.
Key properties of TBAC/IBAC:
1. Task/Intent-Scoped — Permissions are explicitly bound to an individual action, task, or agent intent
2. Time-Bound — Each authorization is short-lived, tightly tied to the lifespan of the relevant task/intent
3. Resource-Constrained — Permissions narrowly target only what is necessary for that task/intent
4. Trigger-/Intent-Aware — Authorization logic considers both how (and why) an action was initiated and what the agent intends to achieve
5. Delegation-Safe — When agents delegate or collaborate, their effective permission scope only shrinks (never broadens) through each handoff
6. Externally Enforced — All decisions, constraints, and audit logs are handled in an external, policy-driven engine—never just inside agent code or process
Existing Authorization Patterns Fail for Autonomous Agents
OAuth 2.0 assumes a human-driven request-response model. Autonomous agents break that assumption:
• Triggered by machine events (alerts, webhooks, schedules)
• Operate without human session context
• Delegate tasks across multiple agents
• Require different permissions per execution
Why Existing Patterns Fail
Service Accounts
No human traceability, no task context — all executions look identical.
Impersonation
Grants full user permissions — violates least privilege.
On-Behalf-Of (RFC 8693)
Assumes a human-originated request and linear delegation. Agent systems are event-driven and branching.
OAuth is necessary, but insufficient. TBAC adds a task-aware authorization layer above token systems.
Trust Model for Autonomous Agents
TBAC requires a trust anchor to verify agent identity before granting permissions.
AGNTCY Identity provides:
• Verifiable agent identity (Agent Badges)
• Capability metadata
• Issuer traceability (org/human accountability)
The TBAC engine uses identity as a gate, not the decision itself.
Proposed PoC Scope
Phase 1: TBAC/IBAC Mapping & Agntcy Integration
Phase 2: Identity Integration
Phase 3: Tooling Enhancements
Phase 4: Delegation & Auditing
Deliverables
References