Context
Operators need to trigger pre-registered robot-side actions from Keystone, but Keystone must not accept arbitrary commands or bypass auditability. Action requests should reference an allowlisted action ID and validated arguments only.
Scope
- Add an action request model with
request_id, robot_id, action_id, args, status, requested_by, requested_at, expires_at, and audit metadata.
- Create an API for operators or services to submit action requests against a robot action catalog entry.
- Validate arguments against the catalog-provided schema before accepting a request.
- Enforce RBAC and approval requirements for high-risk actions.
- Write audit events for request creation, approval, cancellation, and status changes.
- Prevent arbitrary shell commands or unmanaged script paths from being submitted.
Acceptance Criteria
- Valid action requests are persisted with a stable request ID.
- Unknown action IDs, invalid arguments, unauthorized users, and expired approval flows are rejected clearly.
- All request lifecycle changes are auditable with the requesting user and robot identity.
- The API never accepts raw shell commands as request payload.
- Tests cover successful creation, schema validation failure, RBAC denial, approval-required actions, and audit log creation.
Depends On
Related
Context
Operators need to trigger pre-registered robot-side actions from Keystone, but Keystone must not accept arbitrary commands or bypass auditability. Action requests should reference an allowlisted action ID and validated arguments only.
Scope
request_id,robot_id,action_id,args,status,requested_by,requested_at,expires_at, and audit metadata.Acceptance Criteria
Depends On
Related