Excessive Agency Monitoring: Scope, Approvals, Tools, and Plans

What 1-SEC checks

The LLM Firewall examines reported decisions/plans for actions without required approval, selected action keywords under readonly/read_only/limited scopes, large tool counts, complex plans, and elevated cross-agent delegation. These are explicit fields and heuristics, not an inferred capability graph.

Read the implementation: analyzeExcessiveAgency

Required telemetry and context

Relevant input events: agent_decision, agent_plan. Use a trusted producer at the real application boundary.

• agent_id
• action
• decision
• scope
• approval_required (string)
• approval_given (string)
• tool_count (number)
• plan_steps (number)

Field names above describe relevant context, not a complete API request. Consult the current event contract for envelope and detail requirements. Preserve booleans, numbers, and strings as the receiving handler expects them. Agent-provided text cannot independently verify identity or authorization.

Deployment, prevention, and response

Bind plan/approval metadata to a trusted orchestrator and record actual approved operations. Use task-specific benign plans when reviewing false positives. Enforce authorization in the tools and add external hard limits where required instead of assuming tool-count alerts impose a cap.

Record the source event, affected agent/host, actual target, policy decision, and response result. Review enforcement configuration separately from detection. A recommendation, selected action, dry-run record, and completed action are different outcomes.

Reproduce the source fixtures

From a checkout of the linked 1-SEC source revision, run the selected fixtures with the repository's Go toolchain. These commands run tests; they do not execute a real attack against your systems.

go test ./internal/modules/llmfirewall -run '^(TestExcessiveAgency_NoApproval|TestExcessiveAgency_NormalAction_NoAlert|TestExcessiveAgency_ScopeViolation)$' -count=1

The referenced source fixtures ran in the selected local package suites. Helper tests and synthetic events establish only the assertions shown, not production prevention or framework compatibility.

func TestExcessiveAgency_NoApproval(t *testing.T) {
	cp := makeCapturingPipeline()
	f := startedFirewallWithPipeline(t, cp)

	ev := core.NewSecurityEvent("test", "agent_decision", core.SeverityInfo, "agent action")
	ev.Details["action"] = "delete_database"
	ev.Details["agent_id"] = "agent-007"
	ev.Details["approval_required"] = "true"
	ev.Details["approval_given"] = "false"
	f.HandleEvent(ev)

	if !cp.hasAlertType("excessive_agency_no_approval") {
		t.Errorf("expected excessive_agency_no_approval alert, got %v", cp.alertTypes())
	}
}

func TestExcessiveAgency_NormalAction_NoAlert(t *testing.T) {
	cp := makeCapturingPipeline()
	f := startedFirewallWithPipeline(t, cp)

	ev := core.NewSecurityEvent("test", "agent_decision", core.SeverityInfo, "normal")
	ev.Details["action"] = "read_file"
	ev.Details["agent_id"] = "normal-agent"
	ev.Details["scope"] = "readwrite"
	f.HandleEvent(ev)

	if cp.count() > 0 {
		t.Errorf("expected no alerts for normal agent action, got %v", cp.alertTypes())
	}
}

// ─── RAG / Vector Embedding (LLM08:2025) ─────────────────────────────────────

func TestExcessiveAgency_ScopeViolation(t *testing.T) {
	cp := makeCapturingPipeline()
	f := startedFirewallWithPipeline(t, cp)

	ev := core.NewSecurityEvent("test", "agent_decision", core.SeverityInfo, "agent action")
	ev.Details["action"] = "delete_user_records"
	ev.Details["agent_id"] = "readonly-agent"
	ev.Details["scope"] = "readonly"
	f.HandleEvent(ev)

	if !cp.hasAlertType("excessive_agency_scope_violation") {
		t.Errorf("expected excessive_agency_scope_violation alert, got %v", cp.alertTypes())
	}
}

Tuning, evaluation, and coverage limits

The approval fields in this path are parsed as strings, unlike the boolean verification fields in identity/management APIs. Incorrect field types can disable a check. A complex plan or many tools can be legitimate, and an alert does not enforce a hard capability or spending budget.

Evaluate this behavior with representative authorized activity and a controlled known-positive case. Investigate the exact rule, inputs, and state before suppressing an alert. Do not assume a hard-coded heuristic is a configurable setting. Measure your own deployment; the source fixtures do not establish a benchmark, detection rate, compliance certification, or incident-prevention claim.