fix(go-policy): check rate-limit threshold before incrementing counter

[Ken Tannenbaum (finnoybu)]

Summary

checkRateLimit in agent-governance-golang/packages/agentmesh/policy.go:153-156 incremented the counter first and then compared:

state.count++
if state.count > rule.MaxCalls {
    return RateLimit
}
return Allow

Once the limit was reached, every subsequent call within the same window continued to increment the counter on its way to returning RateLimit. The counter grew unboundedly until the window expired.

The growth was internally harmless — the next window reset to 1 — but the counter no longer represented the admit/reject state, so any test or observability hook reading state.count after a deny would see values larger than MaxCalls.

Change

Reorder to check-then-increment, using >= so MaxCalls is the inclusive bound:

if state.count >= rule.MaxCalls {
    return RateLimit
}
state.count++
return Allow

A 3-call limit now goes: counter 0→1→2→3 across three allowed calls; the 4th call sees count >= 3, returns RateLimit, leaves count at 3.

Tests

New TestRateLimitCounterDoesNotGrowAfterDeny: log 3 allowed calls then 3 denied calls; assert state.count == 3 after each phase. The existing TestRateLimiting continues to pass — its semantics ("admit N, then deny") are unchanged.

go test -run TestRateLimit ./... -v
  --- PASS: TestRateLimiting (0.00s)
  --- PASS: TestRateLimitCounterDoesNotGrowAfterDeny (0.00s)

Note on REVIEW.md item #7

This is part 1 of REVIEW.md item #7. Part 2 — keying the rate limiter by (action, agent_id, tenant) so one noisy caller doesn't starve all others — ships as a separate PR because it requires threading context through to checkRateLimit and updating the in-tree caller (middleware.go:256 currently passes nil context).

Test plan

• CI passes
• Existing rate-limit tests continue to pass

---

Surfaced as part of the AEGIS Initiative review of the agent-governance-toolkit (HIGH severity, Go section). Filed by Ken Tannenbaum (AEGIS Initiative).

[github-actions]

🤖 AI Agent: code-reviewer — View details

TL;DR: 1 blocker, 0 warnings. The counter increment logic in checkRateLimit was incorrect, leading to unbounded growth after reaching the limit.

#	Sev	Issue	Where
1	CRITICAL	Counter incremented before limit check, causing incorrect state representation	agent-governance-golang/packages/agentmesh/policy.go

Action items: Reorder the counter increment logic in checkRateLimit to check the limit before incrementing.

Warnings: No warnings found.

[github-actions]

🤖 AI Agent: docs-sync-checker — Docs Sync

Docs Sync

• checkRateLimit() in policy.go -- missing docstring
• README.md -- no section appears to require an update
• CHANGELOG.md -- missing entry for behavioral change in rate-limiting logic

[github-actions]

🤖 AI Agent: test-generator — `policy.go`

policy.go

• TestRateLimitCounterDoesNotGrowAfterDeny -- validates that the counter does not exceed MaxCalls after reaching the limit.

policy_test.go

• No gaps identified. Test coverage looks good.

[github-actions]

🤖 AI Agent: security-scanner — View details

No security issues found.

[github-actions]

🤖 AI Agent: breaking-change-detector — API Compatibility

API Compatibility

Severity	Change	Impact
High	Modified behavior of checkRateLimit to check before incrementing state.count.	This change alters the behavior of the rate-limiting logic. Code relying on the previous behavior (where state.count could grow unboundedly after reaching the limit) may break or behave differently.

[github-actions]

PR Review Summary

Check	Status	Details
🔍 Code Review	❌ Failed	Issues detected
🛡️ Security Scan	✅ Passed	No issues found
🔄 Breaking Changes	✅ Completed	Analysis complete
📝 Docs Sync	✅ Completed	Analysis complete
🧪 Test Coverage	✅ Completed	Analysis complete

Verdict: ❌ Changes needed

[github-actions]

🟡 Contributor Check: MEDIUM

Check	Result
Profile	MEDIUM
Credential	NONE
Overall	MEDIUM

Automated check by AGT Contributor Check.

[Imran Siddique (imran-siddique)]

Reviewed. Security fix from finnoybu audit.

[Imran Siddique (imran-siddique)]

Merge conflict after sibling PRs landed. Please rebase on main and force-push to resolve.

[Imran Siddique (imran-siddique)]

Superseded by #2232 which applies this fix (check-before-increment).