Skip to main content

Enterprise: Admin-Guarded Actions

Problem Statement​

Certain enterprise operations (changing billing plans, modifying security settings, enabling integrations) require administrative privileges. These actions must declare their permission requirements so agents don't attempt unauthorized operations.

Why Human-Only Semantics Fail​

  • Admin-only buttons look identical to regular buttons
  • Permission requirements are enforced server-side with no client-side declaration
  • Role hierarchies (viewer < editor < admin < super-admin) aren't in the DOM
  • Failed permission checks return generic "Forbidden" errors

Why Scraping Fails Here​

  • Admin UI sections may be entirely absent from non-admin DOM
  • Permission checks happen via API, not DOM visibility
  • Multi-factor authentication gates are JavaScript-driven
  • Admin panels often have different URL structures

How AXAG Eliminates Scraping​

Admin-guarded actions declare axag-required-roles and axag-preconditions with specific permission requirements. Agents check role compatibility before attempting the action.

Annotated UI Example​

<!-- Change Billing Plan -->
<button
  axag-intent="billing.change_plan"
  axag-entity="billing"
  axag-action-type="write"
  axag-required-parameters='["plan_id"]'
  axag-optional-parameters='["billing_cycle","promo_code"]'
  axag-preconditions='["caller must have billing_admin role","account must not have past-due invoices"]'
  axag-postconditions='["plan changed","prorated charges applied","confirmation email sent"]'
  axag-risk-level="critical"
  axag-confirmation-required="true"
  axag-approval-required="true"
  axag-approval-roles='["super_admin"]'
  axag-idempotent="true"
  axag-side-effects='["billing_change","proration","email_notification"]'
  axag-scope="tenant"
  axag-description="Change the organization's billing plan"
>Change Plan</button>

<!-- Disable MFA (Security Setting) -->
<button
  axag-intent="security.disable_mfa"
  axag-entity="security_settings"
  axag-action-type="write"
  axag-required-parameters='["user_id"]'
  axag-preconditions='["caller must have security_admin role","MFA must be currently enabled"]'
  axag-postconditions='["MFA disabled for user","security audit log updated"]'
  axag-risk-level="critical"
  axag-confirmation-required="true"
  axag-approval-required="true"
  axag-approval-roles='["security_admin","super_admin"]'
  axag-idempotent="true"
  axag-side-effects='["security_posture_change","audit_log"]'
  axag-scope="tenant"
  axag-description="Disable multi-factor authentication for a user"
>Disable MFA</button>

Semantic Manifest Excerpt​

{
  "intent": "billing.change_plan",
  "entity": "billing",
  "action_type": "write",
  "operation_id": "billing_change_plan",
  "description": "Change the organization's billing plan",
  "required_parameters": [{ "name": "plan_id", "type": "string" }],
  "optional_parameters": [
    { "name": "billing_cycle", "type": "string", "enum": ["monthly", "annual"] },
    { "name": "promo_code", "type": "string" }
  ],
  "risk_level": "critical",
  "confirmation_required": true,
  "approval_required": true,
  "approval_roles": ["super_admin"],
  "idempotent": true,
  "scope": "tenant",
  "side_effects": ["billing_change", "proration", "email_notification"],
  "preconditions": [
    "caller must have billing_admin role",
    "account must not have past-due invoices"
  ],
  "postconditions": ["plan changed", "prorated charges applied", "confirmation email sent"]
}

Constraints & Safety Notes​

  • Critical risk: billing changes have immediate financial impact
  • Dual gate: requires both confirmation AND approval from a super_admin
  • Agents MUST check preconditions before attempting: verify role, verify no past-due invoices
  • Disabling MFA is a security-sensitive operation that logs to audit trail
  • Both actions are idempotent (changing to the same plan, disabling already-disabled MFA)
  • approval_roles declares WHO can approve, not just that approval is needed