Permission comes first.
Systems, access, methods, data handling, contacts, and stop conditions are agreed before work starts.
About BalhenceGood security starts
Good security starts
with good questions.
Balhence is an AI-native security practice: approved AI tools assist research and analysis, while a person validates every finding and owns delivery. We use recognized testing methodologies to plan the assessment, with scope, permissions, data handling, and safety agreed before any testing begins.
The practiceCurious about how
Curious about how
things really work.
Balhence is an AI-native security practice working across penetration testing, research, code review, and defensive engineering. The job is to understand your systems well enough to find the problems that matter and explain what to do about them.
That might mean following a permission through a web app and its API, reviewing cloud access, or checking what an AI agent is allowed to do. Mobile apps, infrastructure, identity, source code, and detection are part of the picture too.
AI helps with research, analysis, and building tools. It can also be wrong. A person checks the evidence, reviews the work, and takes responsibility for what we deliver.
If your project needs specialist skills or equipment, we'll say so early. We agree on what we can take on before making a commitment.
Working standards
The basics we don't skip.
Show the evidence.
A plausible tool result isn't enough. We check findings and changes before asking your team to act on them.
Use the smallest safe check.
Controlled accounts and synthetic records help us answer the question without touching more data than necessary.
Make time for questions.
The handover includes a walkthrough and whatever validation or re-testing is agreed in your scope.
How we use AIUseful tools.
Useful tools.
Our responsibility.
We use AI for research, analysis, code, and documentation where it helps the work. Your approval determines which tools and data we can use. Human review stays part of the process.
Where AI fits
- Researching technologies and organizing approved project context
- Connecting observations across code, configuration, and workflows
- Helping review threats, controls, and detection coverage
- Developing custom defensive tools and repeatable checks
- Organizing redacted evidence with traceable sources
- Drafting documentation, remediation options, and handover notes
What people own
- The scope, permissions, and safety of each action
- Architecture decisions and the tradeoffs behind them
- Validation of findings and review of generated code
- The meaning of the evidence and its business impact
- Recommendations, priorities, and quality of delivery
- Checking fixes and deliverables against the agreed requirements
Your data and AI
AI use is documented in the scope and rules of engagement. No public model receives client credentials, tokens, customer records, source code, or unredacted vulnerability evidence unless the client explicitly approves the provider, purpose, and processing terms. No model autonomously tests production.
Read how we use AI in testingPenetration testing methodology and working standards
We use recognized references to organize coverage and explain the limits of an assessment. The methods used depend on the systems and the agreed scope.
- Web and API: OWASP WSTG, OWASP Top 10, and OWASP API Security Top 10.
- AI applications: OWASP LLM Top 10 and OWASP Agentic Applications Top 10.
- Assessment planning: NIST SP 800-115 and PTES.
- Technique context, where relevant: MITRE ATT&CK.
These are methodology references, not certifications or endorsements. Every reported finding is reviewed by a person, and the report identifies what was checked, excluded, or left unverified.
For features you build with models or agents, see AI and LLM penetration testing.
Balhence / Santulan
Security has to work with your product.
The name Balhence comes from santulan, meaning balance. Your team has releases to ship, customers to support, and data to protect. Security advice needs to account for all of that.
A recommendation that ignores the way your team works is unlikely to stick. We'll explain the risk, talk through the tradeoffs, and help you choose a fix you can maintain.
Before you choose
Take a look at the work.
Our sample penetration test report uses fictional systems and findings to show the format. For other projects, we'll agree on the deliverable and how to check it before starting.
Work you can inspect
- A detailed sample report for penetration testing
- Methods and deliverables matched to the engagement
- Clear scope, exclusions, and safety controls
- Published AI-use and client-data guardrails
- Practical handover and agreed validation checks
- Direct access to the person responsible for delivery
Clear expectations
- The work covers the systems and outcomes we agree on
- Results reflect the version and access available during the work
- Every reported issue is checked by a person
- No assessment can guarantee that every vulnerability has been found
- Your auditor or reviewer decides whether deliverables meet their needs
- Testing starts only after written authorization
Publication and evidence standards
Balhence publishes buyer guides to help teams plan assessments and understand deliverables. Organization bylines link to this approach. A guide describes how to prepare for a service; it does not establish an individual's certification or a client's results.
- Sources and dates: methodology and regulatory references link to the responsible publishers. Publication dates identify the original article; modification dates reflect substantive content changes.
- Examples: worksheets and the sample report use fictional systems and findings. They demonstrate scope and report format, not client outcomes.
- Research: field notes are anonymized. Illustrative code and defensive checks are labeled separately from observations.
- Corrections: send a page URL, the statement, and a supporting source to contact@balhence.com. Please exclude credentials and confidential findings.
Start with the penetration testing guides or compare assessment types and their limits.
Working together
You won't have to keep starting over.
The person who scopes the project stays involved in technical decisions, evidence review, and the handover. You can ask questions with the context already in place.
- 01Direct communicationTalk to someone who understands your goals and the work underway.
- 02A realistic scheduleWe accept work only when we can support the agreed timeline.
- 03The right mix of skillsWe shape the approach around your problem and agree on specialist support when needed.
What we agree before starting.
The systems, methods, data handling, and checks that define the work.
scope: systems + workflows
methods: research / review / build
data: approved handling only
result: validated deliverables
methods: research / review / build
data: approved handling only
result: validated deliverables
- Named business and technical contacts
- Permissions and boundaries documented
- Evidence handling agreed
Getting started
What are you working on?
A rough idea is enough. Tell us what needs attention and we'll work through the next step with you.