With AI, attacks got faster, more sophisticated and harder to spot. Hify uses AI agents to attack your systems first, with your authorization. Experts confirm what is a real risk, and a dashboard shows you whether the company is getting safer.
Company security
2 applications · updated 2 min ago
298% lower since Hify
| Month | Index |
|---|---|
| January (before Hify) | 86 |
| February (before Hify) | 90 |
| March (Hify activated at month end) | 89 |
| April | 5 |
| May | 3 |
| June | 4 |
| July | 2 |
| August | 3 |
| September | 2 |
Biggest risk today: accounts and access, 4 out of 100. No critical risks open.
New endpoints ship and access rules change with every deploy. With Hify, each application runs in cycles ordered by risk, and a relevant change triggers a targeted test. You see, month by month, whether exposure goes down.
Tests per application52 weeks of deploys
Annual pentest: applications A, B and C are tested once, in the first three weeks of the year. After that they go 49 weeks without testing, and 9 of 10 relevant changes go live untested.
It maps what is exposed, tests with your business context and delivers each finding with proof. Each screen below answers a question your team asks.
Overview
2 applications · 308 routes · updated Sep 26
| Month | Critical | High | Medium |
|---|---|---|---|
| March (Hify activated at month end) | 5 | 8 | 9 |
| April | 0 | 1 | 2 |
| May | 0 | 1 | 1 |
| June | 0 | 0 | 2 |
| July | 0 | 1 | 1 |
| August | 0 | 0 | 2 |
| September | 0 | 1 | 1 |
| Month | Days |
|---|---|
| January (before Hify) | 22 days |
| February (before Hify) | 20 days |
| March (Hify activated at month end) | 21 days |
| April | 5 days |
| May | 4 days |
| June | 5 days |
| July | 4 days |
| August | 4 days |
| September | 3 days |
Assets and coverage
2 applications · last tested Sep 25
New route detected POST /v1/pix/devolucao
api.exemplo.com.br/v1 · since Sep 22 · not tested yet
| Application | Routes | Tested | Untested | Open |
|---|---|---|---|---|
| app.exemplo.com.brWeb · last tested Sep 25 | 212 | 175 | 37 | 1 |
| api.exemplo.com.br/v1API · last tested Sep 25 | 96 | 88 | 1 new8 | 1 |
Scope imported from OpenAPI v3 Postman HAR
Findings
1 in retest · 3 fixed · 1 awaiting validation
| Finding | Severity | Status and deadline | Owner |
|---|---|---|---|
| role field accepted in the bodyHFY-0148validated by an expertPATCH /v1/accounts/{id} | Critical | Fixedon Sep 24 | Platform |
| Daily limit bypassed with parallel requestsHFY-0157validated by an expertPOST /v1/transfers | Critical | Fixedon Sep 25 | Cards |
| Reusable password reset tokenHFY-0160POST /reset | High | Observedawaiting validation | after validation |
| User enumeration by CPFHFY-0151validated by an expertPOST /login | Medium | In retestsince Sep 24 | Accounts |
| Reading another account's dataHFY-0142validated by an expertGET /v1/accounts/{id} | High | Fixedon Sep 18 | Accounts |
Deadlines set by your team: Critical 7 d · High 15 d · Medium 30 d · Low 90 d · counted from Validated
Authorization matrix
api.exemplo.com.br/v1 · expected set by your team
| Endpoint | individual customer | business admin | business operator |
|---|---|---|---|
| GET /v1/accounts/{id}another customer's account | expected: deny · actual: 200 on Sep 14HFY-0142 fixed | denied | denied |
| PATCH /v1/accounts/{id}change the role field | denied | allowed | expected: deny · actual: 200 on Sep 22HFY-0148 fixed |
| POST /v1/transfersfrom own account | allowed | allowed | allowed |
| GET /v1/invoices/{id}invoice from own account | allowed | allowed | denied |
Tested with test accounts per role; recorded login with test OTP and session renewal.
Reports
September 2026 cycle · 2 applications · 4 findings validated, 1 awaiting validation
Exemplo S.A. · company security in September
The risk index fell from 89 to 2 since Hify came in at the end of March. No critical risks open: the 2 found in September were fixed within 3 days.
Risk index
2 of 100 · low
Trend, January to September
| Month | Index |
|---|---|
| January (before Hify) | 86 |
| February (before Hify) | 90 |
| March (Hify activated at month end) | 89 |
| April | 5 |
| May | 3 |
| June | 4 |
| July | 2 |
| August | 3 |
| September | 2 |
| Risk | Impact | Owner | Fixed in |
|---|---|---|---|
| Any user could become an administrator | Access to every customer's account | Platform | 2 d |
| The daily transfer limit could be bypassed | Direct financial loss | Cards | 3 d |
Compliance
Cycle findings, with evidence and fix
Security testing attestation
Finding mapping
Application-layer evidence for PCI DSS v4.0.1, req. 11.4, and for the periodic testing required by Res. CMN 4.893 and Res. BCB 85 (payment institutions). The network layer stays covered by the pentest in your plan.
See these screens live, with your team's questions.
Book a demoAn annual pentest goes deep, but holds for one date. A scanner always runs, but doesn't know your business rules. Bug bounty depends on who shows up. Hify tests in cycles, with multiple roles, and every finding arrives validated.
| Annual pentestconsultancy, on a set date | Scanner (DAST)automated scanning | Bug bountyoutside researchers, paid per finding | HifyAI agents and expert validation | |
|---|---|---|---|---|
| Frequency | once a year | every scheduled scan or build | while the program is open | in cycles, in risk order, and after relevant changes |
| Authorization and business logic flaws IDOR/BOLA | yes, within the test period | limited: doesn't know the business rules | depends on the researcher | yes, with authorization and business logic agents |
| Authenticated tests with multiple roles | yes, with the accounts provided | yes | depends on the access the program gives | yes, each role against the routes in the authorization matrix |
| Reproducible proof of exploitation | yes, in the final report | alert with the request, without the attack path | yes, in the researcher's report | request and response in every finding |
| Who filters false positives | the consultant | your team | the program's triage, then your team | a Hify expert, before it reaches your team |
| Retest of the fix | if it's in the contract | on the next scan | depends on the researcher | on the same attack path, with before and after |
| Shows what wasn't tested, and why | depends on the report | shows what it crawled, without the reason | no | yes, route by route, with the reason |
| Fits into the deploy CI | no | yes | no | yes, a pipeline step triggers a targeted test |
| Cost predictability | fixed price per project | subscription | variable, paid per finding | per application, based on the plan; doesn't vary with the number of findings |
| Internal network, social engineering and physical testing | yes, when contracted | no | rarely in scope | outside the platform's scope |
General comparison: pentest contracts, scanners and bug bounty programs vary. For internal networks, social engineering and physical testing, a traditional pentest is still the way to go.
See a finding from scope to retestSee what your team gets with every finding: request, response, impact, fix and proof that the fix worked. A fictional case with synthetic data.
Target, access level, test accounts and forbidden routes are recorded before the first request. Anything not on the list is blocked by policy.
The authorization agent tested three hypotheses: one reproduced, two were discarded. Your team gets what holds up, not a list of suspicions.
Request and response stay in the finding, with personal data masked. The developer reproduces it alone, without asking anyone for details.
A Hify expert confirms the flaw and describes what leaks, who is affected and what the attack requires. The severity comes justified, ready to prioritize.
The guidance points to the cause and the 11 routes with the same pattern. The finding becomes a ticket with an owner, and the deadline follows the SLA policy you set.
The same request runs again after the change. The finding only closes with proof in the history: 200 OK before, 404 after.
Only H-01 moves on to validation. The discarded ones stay in the run log.
Requestaccount-a session
GET /v1/accounts/7f3c…e21 Authorization: Bearer ‹account-a session›
The ID 7f3c…e21 belongs to account-b. The session is account-a's, and the API responds anyway.
Responseaccount-b data
HTTP/1.1 200 OK
{
"id": "7f3c…e21",
"nome": "Mar*** S***",
"email": "m***@exemplo.com.br",
"cpf": "***.***.***-12"
}
Why High, not Critical: it exposes any customer's personal data, but requires a valid session and only allows reading.
Check on the server that the account_id belongs to the session before responding. Return 404, not 403, so you don't confirm the ID exists.
if (account.id !== session.account_id) {
return res.status(404)
}
11 routes take an account identifier and follow the same pattern
In the demo, you walk through this finding in the dashboard, from scope to retest. The Hify expert validates, AppSec prioritizes, Engineering fixes and the CISO follows along.
Book a demoYou set the hosts, routes, test accounts, time window and request rate limit. Every request is logged, and anything out of scope is blocked by policy before it goes out.
Autonomous agents are unnerving because they choose the next step on their own. With Hify, an agent only reaches what is on the allowlist, using the test accounts you registered, inside the window and the rate limit. Your WAF recognizes the traffic by its fixed IPs and the run header, and anything on the denylist is never touched.
Who uses it AppSec builds the scope, the CISO approves it and infrastructure allows the IPs in the WAF.
Scope and guardrails
Approved by CISO (sample) on Sep 11
A report at the end of the test doesn't show what the agent tried along the way. In the activity view, each hypothesis shows up with its route, response and result, and an expert reviews what holds up. If something goes off plan, your team pauses the run right here.
Who uses it The CISO follows along and pauses if needed. AppSec audits the log.
Activity
Started Sep 25 22:00 · 7 agents · 5 req/s
Before approving an agent, the risk team wants to know where the data goes. These are the five questions Hify's security questionnaire answers in writing.
Ask for the questionnaire in the demoAll five answers come in writing in the security questionnaire, provided under NDA.
A ticket with an owner and a deadline, an alert in the team channel, a link to the fix PR and a retest when the deploy ships. No spreadsheets, no PDFs lost in email.
The ticket and alert are created when the expert validates. Your backlog gets a reproduced finding, not a raw alert.
Daily limit bypassed with parallel requests
Hify expert (sample), Sep 22
Routing rule Validated Critical: ticket in SEG, alert in #appsec-security
In the owning team's project, with evidence, a suggested fix and the deadline from your policy. Nobody retypes findings from a PDF.
SEG-231 · Daily limit bypassed with parallel requests
Description
The team hears about it the day it's validated, not at the monthly meeting. The alert links to the finding and the ticket.
Hify app Sep 22
New validated finding: HFY-0157 Critical on api.exemplo.com.br/v1 (staging) · owner Cards team · due Sep 29
1 reply · Cards team
The fix PR shows up on the finding. AppSec tracks progress without chasing status in meetings.
Per-account daily limit lock (#812)
fix/seg-231 into main
After the merge, the pipeline deploys to staging and calls Hify to rerun the attack. The finding only closes with proof in the history.
On push to main
$ hify run --app api.exemplo.com.br --finding HFY-0157 --wait
retest scheduled for merge
After the deploy, the retest replays the same attack path. If it no longer reproduces, the finding closes with proof in the history. In retestFixed
The validated finding reaches Claude Code, Cursor or Codex with the request, the response and the suggested fix. The agent prepares the PR, a developer reviews it and Hify reruns the attack before closing the risk.
Claude Code
Cursor
Codex
GitHub Copilot
Windsurf> fix finding HFY-0157 hify.get_finding HFY-0157 · Critical · validated by an expert Daily limit bypassed with parallel requests POST /v1/transfers · evidence and suggested fix editing src/transfers/limit.ts tests 42 passed PR opened #812 Per-account daily limit lock hify.request_retest retest scheduled for merge
JiraOpens in the owning team's project, with evidence, a suggested fix and a deadline. The finding's status follows the ticket.
Slack
Microsoft TeamsA notice in the team channel when a finding is validated, and a reminder when the deadline is close.
Email
WhatsAppSlackThe Hify expert talks directly with your team: a summary of each cycle by email, an immediate WhatsApp alert for critical risks, and a shared Slack channel for questions.
GitHub
GitLab
GitHub ActionsGitLab CIThe fix PR stays linked to the finding, with the retest check. A pipeline step triggers a targeted test after the deploy.
Claude CodeCursorCodexGitHub CopilotWindsurfThrough the Hify MCP server, the agent reads the validated finding with its evidence, prepares the fix and requests the retest.
Executive or technical PDF, or an attestation for customers. Findings as CSV and run requests as HAR.
Admin, AppSec, Developer and Read-only roles. Whoever changed scope, status or access is recorded in the audit log.
After the deploy to staging, a pipeline step retests only the routes that changed. Webhooks are signed, so your system can verify where each event came from.
env: HIFY_TOKEN: ${{ secrets.HIFY_TOKEN }} jobs: hify-test: needs: deploy-staging runs-on: ubuntu-latest steps: - name: Hify on changed routes run: > hify run --app api.exemplo.com.br --scope changed-routes --wait
X-Hify-Event: finding.validated X-Hify-Signature: sha256=9f2c…a41 { "event": "finding.validated", "finding": { "id": "HFY-0157", "severity": "critical", "state": "validated", "ticket": "SEG-231" } }
You don't have to open everything at once. The first run covers one application, from the outside only or with two test accounts. The others come in later, each with its own cadence, in the risk order your team sets.
The platform running in an environment similar to yours: one run, one finding with proof, the retest and the report.
What you open at this stage
You register the URLs and create test accounts per role. Importing the OpenAPI spec is optional. The NDA comes before any sensitive data.
Scope · example
The agents test within scope and an expert reviews what they reproduced. Findings show up in the dashboard with proof, severity and owner.
In the dashboard · HFY-0142 · example
Each application gets a cadence in risk order: in the example, the API every two months and the web app every four. A new route in scope gets a targeted test.
Cadence · next 12 months
Targeted test on the new route POST /v1/pix/devolucao
Examples with sample data.
There's no public price list. The plan price depends on these three points and is set after the demo.
The more access, the more the test can see.
A product company, with two founders building the platform. One has already taken a startup from zero to acquisition; the other comes from consulting on AI agent security. Alongside them, as an advisor, a member of Nubank's board of directors.
Co-founder and CEO
Igor founded Hackr Ads in 2019 and grew it to 45,000 customers and R$ 380 million per month in ad spend managed through the platform. In 2022, he sold Hackr Ads to Conta Simples. At Hify, he applies what he learned building software used every day by thousands of companies.
Co-founder and Chief AI Officer
Lucas works on AI agent security and consulted in this area for Dreamer, whose team later joined Meta (Facebook). At Hify, he runs the agents that attack customers' systems: what each one is allowed to test, how it is controlled and how the result reaches the expert.
Advisor and member of Nubank's board of directors
Rogério has been a member of Nubank's board of directors since 2021 and chairs its audit and risk committee. Before that, he was an audit partner at PwC and CFO of Bunge Brasil, Unibanco, Itaú Unibanco and HSBC Brasil. He knows first-hand what a board asks when the topic is risk.
Short answers on how the platform tests, validates and stores what it finds. The details of your case are for the demo.
No, it complements them. Scanners and DAST look for known patterns, one request at a time. Hify follows multi-step paths with a real session, such as using account-a's session to read account-b's record, uses the application's business rules (who can see, approve or transfer what) and delivers every finding with proof: request, response and impact.
For web apps and APIs, the platform tests far more often than an annual pentest, and every finding goes through an expert before it becomes Validated. Internal networks, social engineering and physical testing are out of scope; for those, manual pentesting stays in your plan.
The environment you define in the scope, with a time window, a requests-per-second limit and destructive methods blocked. The examples on this page use staging.
Where it's stored, for how long and who can access it are answered in the security questionnaire, under NDA, before any sensitive data. In the evidence, personal data is masked, like m***@exemplo.com.br.
First the agent reproduces the signal with other IDs and another account. Then an expert checks the business rule, assesses the impact and rules out false positives. Only what was reproduced and reviewed becomes Validated, and the finding's timeline records when the expert validated it.
Not to get started. You can begin from the outside or with two test accounts, which already show whether one account can read another's data. Code comes in when you authorize it, and the test can see more.
Jira, with the ticket in the owning team's project and the finding's status following the ticket. Slack and Microsoft Teams, with an alert when a finding is validated and deadline reminders. GitHub and GitLab, with the PR linked to the finding and the retest check, plus GitHub Actions and GitLab CI. Also signed webhooks, a REST API and export to PDF, CSV and HAR. Dashboard access uses SSO (SAML or OIDC), Admin, AppSec, Developer and Read-only roles, and an audit log.
Yes. A CI step, like hify run --app api.exemplo.com.br --scope changed-routes --wait in GitHub Actions or GitLab CI, triggers a targeted test on the routes that changed. Full cycles follow each application's cadence.
No findings doesn't mean a secure environment. The report records what was tested, with which access, and what was left out and why, such as a route that requires hardware MFA.
No. Findings stay between Hify and your team, under NDA. Nothing that identifies your company is published without written authorization.
Per application, based on the plan. The weight of each one depends on its complexity: how many URLs, APIs and integrations it involves. Frequency and access level also count. The plan price is set after the demo; there's no public price list.
Tell us how many applications you have in production and how often you ship. In the demo, you follow the whole cycle, from scope to retest.
Review the message and send it to [email protected]. If no email app opens, copy the text below and send it to that address.