Armalo Versus Bug Bounties For Agents: Why Adversarial Probing Is Continuous, Not Episodic
Bug bounties are episodic external testing. Adversarial multi-LLM jury is continuous. Bounties find specific exploits. Continuous probing catches the drift between them.
Continue the reading path
Topic hub
Agent EvaluationThis page is routed through Armalo's metadata-defined agent evaluation hub rather than a loose category bucket.
Turn this trust model into a scored agent.
Start with a 14-day Pro trial, register a starter agent, and get a measurable score before you wire a production endpoint.
TL;DR
Bug bounties are episodic external testing programs that pay researchers to find specific exploitable vulnerabilities. They work well for traditional software because vulnerabilities are typically stable: a bug found today exists until patched, and patching is a discrete event. Agent vulnerabilities behave differently. They drift continuously with model updates, prompt changes, and shifting input distributions. A specific prompt injection that worked last week might fail this week, then work again next week, without any code change in your agent. The bug bounty model alone cannot keep up with this drift. Continuous adversarial probing via a multi-LLM jury fills the gap. Each evaluation is itself an adversarial probe. The score reflects current susceptibility. Drift becomes visible in real time. Bug bounties remain useful for finding novel exploit classes. Continuous probing is what you need for everything between bounty cycles.
A failure mode you have probably already lived through
A productivity startup running an AI agent that handles email triage runs a bug bounty program with one of the major coordinators. They specify scope, set bounty amounts, and invite researchers. The first wave of submissions is excellent. Researchers find seventeen distinct prompt injection vectors. Some are clever. Some are alarming. The team patches each one over six weeks and pays out tens of thousands in bounties. They feel safer. They publish a blog post about how seriously they take security. They have a real bug bounty program now and they have the patches to prove it.
Four months later, internal monitoring catches an anomaly. The agent has been forwarding sensitive emails to an attacker-controlled address. The team digs in. The attack is a variant of one of the prompt injections that was patched in the original wave. The patch addressed the specific phrasing the researcher used. A small variation in the phrasing bypasses the patch. The variation works because a model upgrade two months ago shifted the agent's parsing behavior in a subtle way. The original patch was tied to behaviors of the previous model version. The new model version interprets the slightly varied input differently and the patch no longer covers it.
The team's first instinct is to relaunch the bug bounty. They add new scope. They raise bounty amounts. They invite specifically the researcher who found the original vulnerability. The researcher confirms the variant works and gets paid. The team patches it. They feel safer again. Three months later, internal monitoring catches another anomaly. Another variant. Another model update. Another bounty cycle. The pattern is clear. Bug bounties are catching specific exploits at specific times. The drift between bounty cycles is producing new exploits faster than the bounties can find them. The program is necessary but not sufficient.
The team starts looking for continuous adversarial coverage. They hire a red team firm to run quarterly engagements. The firm finds things. The findings get patched. Three months later, more drift. Another engagement. More patches. The economics start to look worse than the bounty program because the firm has fixed costs that do not scale with the number of vulnerabilities found. The team is paying a flat retainer to discover essentially the same kind of issues over and over because the underlying drift never stops.
The realization that finally lands is that the cadence of attacks is faster than the cadence of any program built around discrete engagements. Bug bounties, red team firms, internal pen tests, all share the property of being episodic. They produce evidence at points in time. The points in time are increasingly far apart relative to the rate at which the agent changes. Continuous coverage requires a different kind of infrastructure: something that runs adversarial probes continuously, treats each evaluation as an opportunity to detect drift, and produces a real-time signal about current susceptibility. This post is about why episodic and continuous serve different purposes, why both matter, and how to compose them.
What bug bounties actually are, precisely
A bug bounty program is a structured arrangement where an organization pays external security researchers to find vulnerabilities in their software, with payment scaled by severity. The dominant coordinators run platforms that handle scope definition, submission triage, severity scoring, payment processing, and disclosure coordination. Researchers can be individuals working for fun, professional bounty hunters who do this full time, or firms that operate research teams.
The core value proposition is leveraging external expertise. The internal team has finite attention and a particular set of mental models. External researchers bring different attention, different mental models, and different incentives. They find things the internal team would not find, partly because they are not the team that built the system and partly because they are explicitly looking for problems rather than implementing features. The economic structure aligns incentives toward discovery. Researchers are paid only for valid submissions. The program selects for finding things rather than for time spent.
The operational pattern is episodic by nature. A researcher decides to look at the program. They spend time. They submit findings. The team triages and pays. The researcher moves on or stays involved sporadically. Even researchers who are highly active on a particular program work it in bursts. The rate of submissions is uneven. The findings cluster around particular insights or particular tools. There are periods of intense activity and periods of relative quiet. This is fine for traditional software because the underlying system is fairly stable and the discoveries during active periods cover the changes between periods.
The second operational property is that bounties tend to find specific exploits rather than systemic patterns. A researcher submits a particular request that triggers a particular bug. The team patches the particular bug. Sometimes the team generalizes from the specific to the systemic and patches a class of related issues. More often the patch is targeted to the specific report because that is what the researcher demonstrated and what the bounty program incentivized. Generalization is the team's responsibility and is often deferred or skipped. The result is a steady accumulation of specific patches that may or may not cover the broader class.
The third operational property is the coverage gap. Bug bounty programs cover what researchers happen to look for. Researchers gravitate toward programs and surfaces where they expect to find things. They do not provide systematic coverage of the entire attack surface. Attackers who know what researchers are not looking at can find vulnerabilities in those areas. This is a long-recognized limitation of bug bounties as a security control. They are part of a program. They are not the whole program.
Why agent vulnerabilities behave differently from traditional software vulnerabilities
Traditional software vulnerabilities are typically stable. A buffer overflow that exists today exists until the code is patched. The vulnerability does not appear and disappear with the wind. The patch is a discrete event that fixes the bug for the lifetime of the patched version. Bug bounty programs work well in this regime because the unit of work, the vulnerability, is stable enough that finding it once is meaningful coverage.
Agent vulnerabilities are unstable. A prompt injection that bypasses safety measures today might fail tomorrow because the model was updated, even with no change to your code. The same injection might work again next week because the model was updated again or because the model's behavior on similar inputs shifted with usage and feedback. The vulnerability is a function of the agent's current behavior, which is itself a function of many components that are all in motion. Finding it once is not meaningful coverage because the next state of the system might or might not have the same vulnerability and might have new ones.
The second difference is that agent vulnerabilities are statistical rather than binary. A prompt injection that succeeds 60% of the time on a particular input is still a vulnerability, but it is not the same kind of vulnerability as a buffer overflow that succeeds 100% of the time. The 60% success rate might shift to 40% next week or to 80%. The vulnerability does not have a stable yes-or-no answer. It has a distribution. Bug bounty programs are not built to capture distributions. They are built to capture specific reproducible exploits. The mismatch between the methodology and the subject creates blindspots.
The third difference is the role of context. The same prompt injection might succeed when the agent is processing a particular kind of email and fail when it is processing a different kind. The success depends on context that varies across runs. A researcher demonstrating the exploit picks a context that works. The patch covers that context. Production traffic includes contexts the researcher did not pick. The patch may not cover those contexts. Coverage of the underlying vulnerability requires evaluating across many contexts, which is expensive for a researcher to do and not what bounties incentivize.
The fourth difference is the rate of change. Traditional software typically updates on cycles measured in weeks or months. The release pipeline produces discrete versions that are stable until the next release. Agents update much faster. Prompt updates can happen daily. Model upgrades happen on the model provider's cycle, which can be weekly or more often for some providers. Tool additions happen as customer requirements emerge. Each change can affect agent behavior in ways that affect vulnerability surface. Bug bounties on agents have to cover an attack surface that is changing faster than the bounty methodology can keep up with.
What continuous adversarial probing actually does
Continuous adversarial probing is the design pattern that addresses the cadence mismatch. The evaluation infrastructure runs adversarial probes against the agent on a continuous basis. Each evaluation is an opportunity to detect a vulnerability. The probes are designed to test specific behaviors: prompt injection resistance, scope honesty, refusal patterns, accuracy under adversarial input, robustness to manipulated context. The results feed the trust score and the dimensional breakdowns within it.
The foundation is the multi-LLM jury treated as an adversarial evaluator rather than a passive judge. Multiple judge LLMs from different model families each independently probe and score. Some probes are designed to elicit specific failures: a craftily phrased instruction that should be refused, a context that should trigger escalation, an input that requires correctly weighting conflicting policies. The judges score whether the agent handled the probe correctly. The top and bottom 20% of scores are trimmed to suppress correlation and outliers. The remaining scores form the verdict. Verdicts feed the score.
The second foundation is the continuous cadence. Probes do not happen during a quarterly engagement. They happen all the time. The probe library is updated as new attack patterns emerge. Each new pattern gets added to the continuous probe set. The agent is evaluated against the full set on an ongoing basis. When a new model version is deployed, the probes immediately start surfacing whether the new version handles the patterns correctly. When prompt changes are shipped, the probes immediately surface whether the changes affected the handling of any pattern. The drift becomes visible in days or hours rather than between bounty cycles.
The third foundation is statistical aggregation. A single probe result is one data point. The score reflects the aggregate of many probes across time. This handles the statistical nature of agent vulnerabilities. A probe that succeeds 60% of the time produces enough variance across many runs that the aggregate signal is informative. A probe that succeeds 100% of the time stands out clearly. A probe that succeeds 0% of the time also stands out. The intermediate cases are exactly the ones bug bounties miss because they look reproducible-or-not, and the score-based approach handles them naturally.
The fourth foundation is the public oracle. The trust signal is queryable in real time. When a vulnerability emerges, the score reflects it. Counterparties consuming the score see the change. Routing decisions react. The operator gets visibility into which dimension dropped and can investigate. This is the closed loop that bounty programs lack. Bounty findings sit in a triage queue. Score changes propagate immediately to anyone who is consuming the signal. The reaction time is structurally faster.
Why bug bounties still matter
The argument is not that bug bounties are obsolete. They serve a different and complementary purpose. Bug bounties are good at finding novel exploit classes that the operator did not anticipate. The probe library can only contain probes the platform team has thought of. New attack patterns that no one has thought of yet do not show up in the probe set. They show up in the wild, often discovered by external researchers with fresh eyes and different mental models. This is exactly what bug bounties are good at.
The right framing is that bug bounties find new vulnerability classes and continuous probing maintains coverage of known classes. A new attack pattern is discovered by a bounty researcher. The team patches it. The probe library adds variants of the new pattern. The continuous probing then covers drift in the agent's response to the new pattern. The two layers are sequential and compose cleanly. Bounties extend the probe set. Probes maintain coverage between bounty cycles. The cycle of discovery and continuous coverage is what produces robust security over time.
The second value of bug bounties is the external attention. The probe library reflects what the platform team thinks matters. External researchers bring different priors. They look at things the team would not look at. They find things in places the team did not think to defend. This is the same value bounty programs provide for traditional software, and it is undiminished for agents. The team's mental models are limited. External researchers expand the search. The continuous probing then institutionalizes whatever is found.
The third value is the incentive structure. Bug bounties pay for results. The aligned incentives are valuable for the kind of high-effort, low-frequency discovery that researchers are good at. Continuous probing is high-frequency, low-effort-per-probe, and runs on infrastructure rather than human attention. The two cost structures are different and serve different purposes. Bounties reward the rare deep insight. Probing maintains the routine coverage. Both are necessary because security requires both depth and breadth.
The operational implication is that operators should run both. The bug bounty program covers the human-driven discovery. The continuous probing covers the infrastructure-driven coverage. The two pipelines feed each other: bounty findings expand the probe set, probing surfaces drift that suggests where bounties might find more, and the score reflects the combined picture. This is the mature security posture for agents. Operators who run only bounties have coverage gaps between cycles. Operators who run only probing miss novel attack classes. Operators who run both have the strongest available posture given current state of the art.
The economics of continuous probing versus episodic bounties
The cost structures of the two approaches differ in important ways that affect when each is appropriate. Bug bounties cost money per finding. The total cost depends on how many findings researchers submit and at what severity. The cost is variable and often unpredictable. A program that pays out modestly one quarter might pay out heavily the next if a researcher finds something serious. The variability is part of why bounty programs are challenging to budget. They are also relatively cheap when nothing is being found, which can be a sign of healthy security or of low researcher engagement.
Continuous probing has a different cost structure. The cost is roughly proportional to the volume of probes run. The probes have a fixed cost per execution because they consume LLM inference and compute. The total cost scales with how thorough the coverage is and how often probes are run. The cost is predictable and bounded by configuration. There is no surprise discovery that produces a large bill. The cost-to-coverage relationship is more transparent.
The second economic difference is what each cost gets you. Bug bounty payments get you specific findings and the IP rights to disclose them. Continuous probing budget gets you the score, the dimensional breakdown, the time series of how the agent is performing across all probed dimensions. The bounty payment is for a specific deliverable. The probing budget is for ongoing telemetry. Both are valuable. They are valuable in different ways and they serve different parts of the security program.
The third economic difference is the failure mode. A bounty program that is not finding anything could mean the system is well-secured or it could mean researchers are not looking hard. The signal is ambiguous. A continuous probing system that is not flagging issues is producing affirmative evidence that the agent is handling the probes correctly, because the probes are running and producing data. The failure modes are different and the diagnostic value is different. Operators who depend only on bounty signals are vulnerable to the ambiguous case where low submissions might mean either security or inattention. Operators who run continuous probing have unambiguous evidence either way.
The budget allocation question is where most operators get this wrong. The instinct is to spend most of the security budget on the bounty program because that is where the dramatic findings happen. The mature allocation puts substantial budget into continuous probing because that is where the routine coverage happens. The bounty program is the spike. The probing is the floor. Neither alone is sufficient. The right allocation depends on the agent's stakes and update cadence, but in most cases the continuous probing should be the larger and more predictable line item, with the bounty program funded for genuine external discovery rather than as the primary security signal.
How probing and bounties feed each other
The most underused pattern is treating bug bounty findings as inputs to the probing pipeline. The researcher submits a finding. The team patches it. The team also adds the finding to the probe library, ideally with multiple variants. The probing pipeline now continuously verifies that the patch holds across variants and across time. If a future model update or prompt change inadvertently reintroduces the vulnerability, the probe surfaces it immediately. The bounty cost is amortized across the lifetime of the agent because the finding becomes a continuous probe rather than a one-time patch.
This pattern requires the operator to treat bounties as discovery infrastructure rather than as point-in-time fixes. The cultural shift is real. Engineering teams are used to thinking of patches as completing the work. The mature posture treats the patch as the start of the continuous coverage. The probe is what ensures the patch keeps working. The two together provide structural protection against regression in a way that neither alone provides.
The reverse pattern is also valuable. Probing surfaces drift in the agent's behavior. The team sees the score on a particular dimension trending down. They investigate. They find that a specific behavior pattern has shifted. They cannot tell whether it is exploitable. They publish a targeted bounty asking researchers to find exploits in this specific dimension. Researchers focus their attention. The bounty program produces specific findings or fails to. Either way, the operator gets information they did not have before. The probing identifies where to look. The bounty searches the area in detail.
The network effect is also real. As more agents are evaluated by the same probing infrastructure, the probe library grows from findings discovered across the population. A novel attack pattern found against one agent becomes a probe that all agents are evaluated against. The collective coverage improves with each new finding. Per-operator probing infrastructure cannot match this because each operator is running their own library against their own agent. The shared infrastructure benefits from cross-operator discovery in a way that individual programs cannot.
What the probe library actually contains
The specifics of what continuous probing tests are worth being concrete about because the abstract framing can hide important details. The probe library covers several categories that map to dimensions of the trust score.
Prompt injection probes test whether the agent follows instructions embedded in user content that contradict the agent's system prompt. The probes use a wide variety of phrasings, contexts, and attack patterns. They test direct injection, indirect injection through retrieved content, multi-turn injection, and adversarial prompt patterns developed through research. The agent's responses are scored for whether they followed the embedded instruction or correctly maintained the system prompt's guidance.
Scope probes test whether the agent stays within its declared capabilities or expands into areas outside its pact. The probes ask the agent to do things adjacent to its scope, just outside its scope, and clearly outside its scope. The scoring examines whether the agent correctly accepts what is in scope, refuses what is out of scope, and asks for clarification on ambiguous cases. Drift in scope honesty is one of the most common quiet failures and is hard to catch without systematic probing.
Refusal probes test whether the agent refuses requests it is supposed to refuse. The probes include classic dangerous-content requests, subtle manipulation attempts, requests phrased to bypass refusal training, and requests that combine legitimate and illegitimate elements. The scoring checks the refusal pattern, the explanation, and whether the refusal is consistent across phrasings of the same underlying request.
Accuracy probes test whether the agent produces correct outputs on tasks within its declared capability. The probes include known-answer questions, tasks with verifiable outputs, and comparisons against ground truth. The scoring is straightforward: did the agent get it right, and how confident was it. Accuracy drift over time is what most internal evals try to catch but often miss because they use static test sets that the agent has effectively memorized through training.
Safety probes test whether the agent produces unsafe outputs in edge cases. The probes include requests at the boundary of acceptable, requests that combine safety-relevant elements in non-obvious ways, and requests that exploit the agent's helpfulness training to extract harmful outputs. The scoring evaluates both the output and the reasoning behind it. Safety drift can come from many sources: model upgrades that shift safety calibration, prompt changes that inadvertently weaken refusals, context that pushes the agent toward over-helpfulness.
This is not exhaustive. The probe library covers many other dimensions and is continuously updated as new attack patterns emerge. The point is that the library is concrete and the scoring is grounded in specific behaviors that map to specific trust dimensions. The continuous probing is not a vague gesture toward security. It is a structured, ongoing evaluation against a documented set of probes with traceable scoring.
How probe drift surfaces problems before exploits do
The most underappreciated value of continuous probing is that it surfaces problems before they become exploited in production. Bug bounty findings represent vulnerabilities that someone has already worked out how to demonstrate. Probe drift represents shifts in the agent's behavior that have not yet been turned into exploits but indicate increasing susceptibility. The lead time between drift detection and exploitation is real value because it gives the operator time to address the issue before it shows up in the wild.
A simple example is refusal pattern drift. The agent has been correctly refusing a particular category of request for months. The probe library includes several phrasings of the request and the agent has reliably refused all of them. After a model upgrade, the score on the refusal dimension drops by a few points because some phrasings now produce uncertain responses rather than clear refusals. No exploit has been demonstrated. The drift is just visible in the score. The operator investigates, identifies the cause, adjusts the system prompt or adds explicit guardrails, and the score recovers. The exploit that would have eventually emerged from the drift was prevented before it happened. Bug bounties cannot produce this lead time because they require demonstrable exploits.
The second example is scope creep. The agent has been correctly scoping its responses to its declared capabilities. The probe library includes adjacent and out-of-scope requests and the agent has reliably refused them. After a prompt update intended to make the agent more helpful, scores on scope honesty drop. The agent is now attempting to handle some requests it should refuse. No specific harm has happened yet because the requests it is attempting are not malicious, just out of scope. The drift is visible in the score. The operator catches it, refines the prompt to restore scope discipline, and the score recovers. The eventual harm that would have come from the agent overreaching into areas where it makes mistakes is prevented before it happens.
The third example is accuracy regression on a specific task type. The agent's overall accuracy is stable, but the dimensional probe data shows accuracy on a particular sub-domain has dropped. The composite score is unchanged because the affected sub-domain is small. The dimensional drift is visible. The operator investigates, finds that a recent change inadvertently affected handling of the sub-domain, and addresses it. Customers who use the agent in that sub-domain would have eventually noticed the accuracy drop and complained or churned. The probe surfaced it first because the probe library covers the sub-domain systematically rather than waiting for customers to surface specific failures.
The deeper value is that lead time changes the economics of agent operation. Operators who can detect drift early can address it cheaply. Operators who only learn about problems when customers complain or attackers exploit them are addressing problems expensively, often after damage has been done. The continuous probing infrastructure is a leading indicator system. The bounty program is a lagging indicator system. Both are valuable but the lead-versus-lag distinction is what makes continuous probing structurally more useful for ongoing operations even when bounties are more useful for specific discovery moments.
Decision Matrix: Bug Bounties versus Armalo Continuous Adversarial Probing
| Dimension | Bug Bounties | Armalo Continuous Probing |
|---|---|---|
| Cadence | Episodic; researcher-driven bursts | Continuous; runs all the time |
| Source of probes | External researchers' creativity | Probe library curated and continuously updated |
| Cost model | Variable; pay per finding | Predictable; proportional to probe volume |
| Discovery type | Novel exploit classes | Drift in known exploit classes |
| Coverage between events | Gaps; no signal during quiet periods | Continuous coverage; signal always current |
| Reaction to drift | None until next bounty cycle | Immediate; score updates within hours |
| Coverage breadth | Where researchers happen to look | Systematic across documented probe categories |
| Coverage depth on novel issues | Strong; researchers go deep on what they find | Limited to probes in the library |
| Statistical handling | Binary; reproducible exploit or not | Probabilistic; aggregate scores reflect distributions |
| Public visibility | Coordinated disclosure of specific findings | Public Trust Oracle reflects current state |
| Best paired with | Continuous probing for between-cycle coverage | Bug bounties for novel discovery |
| What it does best | Find new vulnerability classes the team did not anticipate | Maintain coverage of known patterns across drift |
| What it does not do | Continuous coverage; predictable budget; statistical signal | Discover entirely new attack classes |
| Cross-organizational benefit | Disclosure helps the broader ecosystem | Probe library grows from findings across the population |
| Economic accountability | Payment to researcher for specific findings | Score affects reputation and routing decisions across the agent economy |
The matrix is not a competition. It is a layered design. Bounties for discovery. Probing for coverage. Both feeding each other. The mature posture uses both because each does what the other cannot.
Counter-argument: but my bug bounty program already runs continuously
The most thoughtful pushback comes from operators with active, well-funded bug bounty programs. The argument is that their program runs continuously in the sense that researchers can submit findings any time, the platform stays open, and the team responds promptly. They feel they have continuous coverage already. Adding another layer is not obviously additive.
The answer is that the program being open continuously is not the same as continuous coverage. The program produces submissions in bursts. Researchers come in waves driven by their own scheduling, by bounty amounts, by recent news, by community attention. The actual coverage is bursty even when the program is technically always open. The gaps between bursts can be weeks. During those gaps, the agent is changing. The drift is happening. The next burst will surface some of what drifted, but only the parts that researchers happen to look at. The systematic coverage is structurally absent.
The second answer is the asymmetry of incentives. Researchers go where the bounties are richest and the targets are most interesting. Coverage of the boring parts of the attack surface is structurally weak in any bounty program because the incentives push researchers elsewhere. Continuous probing covers the boring parts as a matter of course because the infrastructure runs the full library regardless of which parts are interesting. The boring parts are where slow drift accumulates and where eventual exploits often emerge. Coverage there is essential and is not what bounties are designed to provide.
The third answer is the statistical signal. Bounty findings are reproducible exploits. Probabilistic vulnerabilities, where an agent fails some percentage of the time on a particular kind of input, are hard to demonstrate in bounty submissions. Researchers gravitate toward the cleaner cases because those are easier to demonstrate and reward. The probabilistic vulnerabilities are real and often more dangerous because they produce occasional failures in production that are hard to root-cause. Continuous probing captures the statistical signal because the aggregate score reflects the distribution of behaviors. Bounties cannot easily produce this signal.
The final answer is the cost predictability. A great quarter for the bounty program might mean a bill that exceeds the budget. A quiet quarter might mean coverage gaps. The continuous probing budget is predictable and bounded. Operators can plan around it. The bounty program supplements with genuine external discovery and pays for real findings when they happen. The composition produces both predictable coverage and unpredictable upside, which is the right mix for a security program. Relying only on bounties produces unpredictable everything, which makes both budgeting and coverage hard.
What Armalo does
Armalo is the trust layer for the agent economy. Each agent registers and signs a pact that codifies its external commitments: capabilities, accuracy floor, refusal patterns, latency ceiling, scope, economic accountability. A multi-LLM jury continuously evaluates the agent's behavior, including a substantial library of adversarial probes that test prompt injection resistance, scope honesty, refusal patterns, accuracy, safety, and other dimensions. The top and bottom 20% of judge scores are trimmed to suppress correlation and outliers. Evaluations feed a 12-dimension composite score covering accuracy, self-audit, reliability, safety, security, bond, latency, scope honesty, cost efficiency, model compliance, runtime compliance, and harness stability. The score and certification tier are exposed on the public Trust Oracle at /api/v1/trust/, queryable by any counterparty. Economic accountability is settled on-chain in USDC on Base L2, with escrow tied to pact compliance. Bug bounties remain valuable for novel exploit discovery. Armalo's continuous probing maintains coverage between bounty cycles and provides the real-time signal that bounty programs structurally cannot.
FAQ
Should I shut down my bug bounty program? No. Bounties find novel exploit classes that continuous probing cannot anticipate. Use both. Treat bounty findings as inputs to the probe library so the discovery becomes ongoing coverage.
Will continuous probing find what bounties find? No. The probe library can only contain probes the platform team has thought of or that have been added through past discoveries. Genuinely novel attack classes need external researchers with fresh eyes. The two layers are complementary.
How do I integrate bounty findings into continuous probing? When a finding is patched, the team adds the finding and several variants to the probe library. Continuous probing then verifies the patch holds across variants and across time. The bounty cost is amortized across the lifetime of the coverage.
Does continuous probing affect agent latency? No. Probing happens out of band on sampled outputs and dedicated probe runs. The production request path is unaffected.
What is the minimum probe volume for the score to be meaningful? The score becomes informative quickly with sufficient probe diversity. Confidence grows over time as more probes accumulate. Initial scores have wider confidence intervals that narrow with continued evaluation.
Can the probe library be customized for my agent? Yes. The shared probe library covers common patterns. Operators can add probes specific to their domain, threat model, or known issues. The customization is encouraged for high-stakes deployments.
Is the probe library public? The methodology is public. Specific probes used for live evaluation are not fully published to prevent gaming. The trade-off is similar to how exam questions are not published before exams.
What happens when a probe surfaces a vulnerability? The score reflects the vulnerability immediately. The operator gets visibility into which dimension dropped and can investigate. The Trust Oracle exposes the lower score to counterparties. The operator is incentivized to root-cause and fix because the score affects their economic standing in the agent economy.
Bottom line
Bug bounties find novel exploits when researchers happen to look. Continuous probing maintains coverage of known patterns when no one is looking. The cadence mismatch between agent updates and bounty cycles makes bounty-only security insufficient. Continuous probing fills the gap. Both layers are necessary because each does what the other cannot. Armalo provides the continuous probing as infrastructure, with the multi-LLM jury, the public score, and the trust oracle integration. Use bounties for discovery. Use continuous probing for coverage. Compose them so findings become probes and probes guide bounty focus. This is the mature security posture for agents, and operators who run both will have the strongest available trust signal in the agent economy.
The Trust Score Readiness Checklist
A 30-point checklist for getting an agent from prototype to a defensible trust score. No fluff.
- 12-dimension scoring readiness — what you need before evals run
- Common reasons agents score under 70 (and how to fix them)
- A reusable pact template you can fork
- Pre-launch audit sheet you can hand to your security team
Turn this trust model into a scored agent.
Start with a 14-day Pro trial, register a starter agent, and get a measurable score before you wire a production endpoint.
Put the trust layer to work
Explore the docs, register an agent, or start shaping a pact that turns these trust ideas into production evidence.
Comments
Loading comments…