Protecting systems since 2018
Cybersecurity for the age of AI.
SecVault finds vulnerabilities across applications, infrastructure, APIs and AI systems before attackers do. Continuous white hat testing, security engineering and remediation for systems that cannot afford to fail.
- Protected
Web application
app.example.com
- Scanning
API
api.example.com
- Investigating
Authentication
auth.example.com
- Protected
Database
primary cluster
- Finding
Cloud
production account
- Protected
Repository
source control
- Remediation
CI pipeline
build and deploy
- Scanning
AI agent
assistant runtime
- Protected
LLM endpoint
model gateway
- Verified
Internal service
operations API
- Investigating
Third party
partner webhook
Web application · 2 connected systems
Protected- Scanning
api.example.com
Authorization boundary
- Protected
app.example.com
Application surface
- Investigating
AI assistant
Prompt injection test
- Remediation
production cluster
Privilege boundary
Broken authorization boundary
/api/accounts/{id}
- Exploit verified
- Remediation available
- Retest pending
SecVault Private Limited · Established 2018 · New Delhi, India
The attack surface changed
Anyone can attack faster now.
Tooling that used to require a specialist is now automated and cheap. Meanwhile the surface being attacked expands with every deployment. A test performed once a year describes a system that no longer exists.
Applications
Shipped weekly, tested annually in most companies.
APIs
Authorization logic spread across services and clients.
Cloud infrastructure
Identity and network boundaries that drift with each change.
AI systems
Models reading untrusted content on behalf of a user.
Agents
Software that acts, with credentials, without a human in the loop.
Third party integrations
Partner webhooks and vendor tokens inside your trust boundary.
Automation credentials
Long lived keys held by pipelines and background jobs.
Repositories
Source, secrets history and the build path into production.
Internal tools
Admin surfaces with the widest permissions and the least testing.
The point is not that attacks are frightening. The point is that visibility has a shelf life, and yours expires every time code ships.
How SecVault works
Discover. Attack. Verify. Fix. Retest. Monitor.
One loop, run continuously. Each stage produces something an engineer can act on, and nothing is marked closed until the original attack fails against the deployed fix.
Step 01 of 06
Discover
Map exposed systems, domains, APIs, cloud surfaces and AI endpoints, including the ones nobody remembered.
- Asset and subdomain discovery
- API and endpoint inventory
- Ownership mapping
The loop restarts every time the software changes.
Services
Security work across the whole surface.
Applications, APIs, cloud, AI systems and the engineering around them. Scope is agreed in writing before any testing begins.
- 01
Continuous Security Testing
Ongoing testing of applications, APIs and infrastructure as they change, rather than one assessment per year.
- Attack surface discovery on a schedule
- Automated scanning with human triage
- Testing tied to release cycles
- Retesting after remediation
- 02
Web and API Penetration Testing
Authorized offensive testing focused on exploitable vulnerabilities rather than scanner volume.
- Authentication and session handling
- Authorization and object level access
- Business logic abuse
- Injection, SSRF and file handling
- 03
AI and Agent Security
Security testing for AI applications, agents, tools and the systems they are connected to.
- Direct and indirect prompt injection
- Tool abuse and excessive agency
- Data exfiltration and cross user leakage
- Retrieval poisoning and unsafe context
- 04
Cloud Security
Review of the identity, network and configuration boundaries that decide what an intruder can reach.
- IAM and privilege paths
- Network and workload exposure
- Storage and secrets handling
- Public surface review
- 05
Application Security
Security across source code, authentication, authorization, APIs, dependencies and deployment architecture.
- Code level review of security controls
- Dependency and supply chain review
- Secrets and build pipeline handling
- Deployment and environment separation
- 06
Fintech Security
Security engineering for systems that move money, hold financial data or act on customer accounts.
- Transaction and ledger integrity
- Permission and approval boundaries
- Partner and payment integrations
- Customer account protection
- 07
Security Engineering and Remediation
We do not stop at a PDF. We work with your engineers until the finding is closed and proven closed.
- Root cause analysis with the owning team
- Fix design and review
- Implementation support where in scope
- Retest and verification
- 08
Security Architecture Review
Review of a system before it reaches production, when changing the design is still inexpensive.
- Trust boundaries and data flow
- Identity and tenancy model
- Blast radius and isolation
- Logging and detection coverage
Security operations
Findings, evidence and status in one place.
Every engagement is tracked the same way: what is being tested, what was found, what has been fixed and what has been verified.
| Severity | Finding | Asset | Status |
|---|---|---|---|
| Critical | Broken object level authorization SV-2081 · /api/accounts/{id} | api.example.com | Open |
| High | Indirect prompt injection through retrieved document SV-2078 · /agent/tools/search | AI assistant | Remediating |
| High | Exposed cloud credential in build log SV-2074 · build/step/deploy | CI pipeline | Retest |
| Medium | Over privileged service account SV-2069 · iam/role/worker | production cluster | Verified |
| High | Server side request forgery in import SV-2063 · /import/url | app.example.com | Open |
| Medium | Unauthenticated webhook accepts replay SV-2058 · /hooks/partner | api.example.com | Remediating |
| Critical | Cross tenant data exposure in report export SV-2051 · /reports/export | app.example.com | Verified |
| Low | Misconfigured storage bucket listing SV-2044 · storage/public-assets | production cluster | Verified |
AI security
AI systems are a new attack surface, not a new feature.
A model that reads untrusted content and calls tools on a user's behalf is an execution path. We test that path end to end.
Direct prompt injection
Instructions in user input that change how the system behaves.
Indirect prompt injection
Instructions hidden in documents, pages, tickets or emails the model reads.
Agent tool misuse
Getting the agent to call a tool with arguments it should refuse.
Sensitive information disclosure
System prompts, keys, internal records and other users' context.
RAG poisoning
Content placed into a retrieval source to influence later answers.
Authorization boundary failures
The agent acting with more authority than the requesting user.
Untrusted content execution
Model output treated as code, SQL, shell or markup downstream.
Excessive permissions
Tokens and roles handed to an agent that only needs a fraction of them.
Browser agent attacks
Pages that manipulate an agent driving a real browser session.
Remediation
A finding is not finished when it is reported.
Reproduction, fix guidance, engineering support and a retest against the deployed change.
Authorization boundary failure
SV-2081 · /api/accounts/{id}
- 01
Finding
Authorization boundary failure on an account scoped endpoint.
- 02
Reproduction
Request replayed with a second tenant token and a captured response.
- 03
Impact
Read access to records belonging to another tenant.
- 04
Recommended fix
Enforce ownership at the data layer, not in the route handler.
- 05
Engineering
Fix reviewed with the owning team before it merges.
- 06
Retest
Original exploit replayed against the deployed change.
- 07
Verified
Attack no longer succeeds. Finding closed with evidence.
Status: verified with evidence
A finding is only closed once the original attack fails against the deployed fix.
Engagements
Start where the risk is.
Four ways to begin. Each one ends with verified findings and a path to fix them.
Security Assessment
A focused review of one application or environment, ending in verified findings and a remediation plan.
Request assessmentPenetration Test
Authorized offensive testing against an agreed scope, with exploit evidence and a retest included.
Scope a pentestAI Security Review
Assessment of an AI application, its agents, tools, retrieval sources and connected systems.
Review an AI systemContinuous Security
Ongoing testing and monitoring that follows your release cycle instead of the calendar.
Discuss continuous coverage
What you receive
- Attack surface assessment
- Verified security findings
- Severity and business impact
- Reproduction steps
- Technical evidence
- Remediation guidance
- Architecture recommendations
- Engineering support
- Retesting
- Ongoing monitoring
- Security reporting
- Executive summaries
How we operate
Rules of engagement.
Offensive work only makes sense with discipline around it.
Authorized scope, in writing
Testing starts after scope, timing and rules of engagement are agreed.
Evidence over volume
A short list of reproduced findings beats a long list of scanner output.
Severity with reasoning
Every rating explains the access it grants and the data it reaches.
Fix oriented
The engagement is not finished when the report is delivered.
Careful with production
Destructive testing is agreed in advance or not performed.
Quiet by default
We do not publish client names, findings or evidence.
Find it before someone else does.
Tell us what you need protected. We will help define the right testing scope, in writing, before anything is touched.