Your environment. Your data. Your controls.
Helium is built for operations that touch sensitive systems and business data. You control where workflows run, what they can access, when a person must approve an action, and how each result is reviewed.
Security control loop
Code to runtime
- Continuous01
Discover
Code, cloud, runtime, and attack surface
- Risk based02
Prioritize
Reachability, exposure, and business context
- Tracked03
Remediate
Owned fixes, approvals, and engineering workflow
- Reviewable04
Verify
Rescans, closure evidence, and reporting
Coverage
Code through runtime
Response
Owned and verified
Evidence
Always current
Private by design
Agens cannot read your operational data and should never need to. The architecture keeps customer content inside approved boundaries and prevents access by our personnel.
You control where Helium runs
Your organization approves the devices, environments, and external compute resources available to each workflow. Processing remains local whenever the work allows it.
Access is limited and governed
Each agent receives only the permissions required for an approved task. Sensitive actions can require review by an authorized person.
Assurance is continuous
Security testing, action logs, approvals, remediation records, and verification evidence remain available for customer and audit review.
Code to runtime risk coverage
Coverage applies to repositories, cloud accounts, images, virtual machines, domains, applications, and developer devices that are connected and configured for the relevant scanner or protection control.
Scope and limitations
Security testing cannot guarantee that software is free of vulnerabilities. These controls improve detection, prioritization, remediation, and verification. They operate alongside access controls, secure engineering practices, independent review, and incident response.
Coverage map
One control plane across the lifecycle
Source
- Repositories
- Dependencies
- Secrets
Build
- CI pipelines
- IaC
- Container images
Deploy
- Cloud accounts
- Virtual machines
- Containers
Operate
- Runtime
- Public domains
- APIs
Findings follow one accountable process covering prioritization, ownership, remediation, rescanning, and reporting.
- 01
Application code
Control scope: Static application security testing (SAST), AI assisted code analysis, code quality checks, and exposed secret detection across Git, CI, and developer tooling.
Customer value: Common coding weaknesses and leaked credentials can be identified before affected code reaches production.
- 02
Open source software
Control scope: Software composition analysis (SCA), dependency reachability, known vulnerabilities, malicious packages, license risk, outdated software, and SBOM generation.
Customer value: We can identify which third party components we use, understand their risk, and prioritize vulnerable or malicious dependencies that can affect the service.
- 03
Cloud and infrastructure
Control scope: Cloud security posture management (CSPM), infrastructure as code checks, container image scanning, virtual machine scanning, and cloud asset context.
Customer value: Misconfigurations and vulnerable infrastructure are detected across both deployment definitions and connected running assets.
- 04
External attack surface
Control scope: Attack surface monitoring and dynamic testing of connected public domains and application endpoints.
Customer value: Internet facing weaknesses and unexpected exposure can be identified from an external attacker’s perspective.
- 05
Runtime and developer devices
Control scope: Runtime protection for supported applications, bot and injection defenses, plus protection against malicious packages and risky developer extensions where deployed.
Customer value: Preventive controls complement preproduction scanning by helping block supported attack classes and software supply chain threats.
- 06
Engineering response
Control scope: Pull request review, CI and release gating, prioritized findings, issue tracker integration, automated fix workflows, rescanning, reports, and audit history.
Customer value: Security findings move into the same accountable engineering process used to ship and verify product changes.
Continuous assurance in practical terms
Our security program continuously tests the systems connected to it. For customers, that means weaknesses can be identified throughout development and operation, prioritized by practical risk, and moved into an accountable remediation process.
Testing continues as systems change
Security reviews are part of normal engineering and operations, rather than an isolated activity before an audit.
For security reviewers
Continuous controls scan connected code repositories, dependencies, container images, cloud accounts, virtual machines, and public domains.
Risk is evaluated in context
Findings are evaluated using exposure, reachability, and asset context so the most consequential issues receive attention first.
For security reviewers
Reachability, exploitability, asset context, and deduplication reduce noise and help prioritize exposed or actionable findings.
Every finding has an owner
Relevant findings are assigned, tracked through remediation, and rescanned to confirm the result.
For security reviewers
PR security review, CI gating, issue synchronization, AutoFix support, and rescanning connect detection to engineering remediation.
Evidence remains available
Client security teams can review the controls in place, the scope of testing, and the process used to manage findings.
For security reviewers
Scan results, audit history, reports, and remediation status support customer reviews and compliance evidence requests.
Penetration testing beyond automated scanning
Penetration testing is available as a separately commissioned engagement alongside continuous platform scanning. It applies coordinated offensive testing to an agreed application and API scope, including authenticated user roles where included in the engagement.
Attack paths tested
OWASP Top 10, authorization failures such as IDOR, injection classes, prompt injection, exposed APIs, critical misconfigurations, and business-logic weaknesses within scope.
Evidence, not alert volume
Potential issues are validated for exploitability and documented with affected assets, reproduction evidence, severity, impact, and remediation guidance.
Audit-grade deliverable
The engagement produces a formal report suitable for customer security review, risk acceptance, remediation planning, and audit evidence.
Fix and retest cycle
Findings can be remediated, tracked, and retested so the final record distinguishes open risk from verified fixes.
Penetration testing is commissioned separately from continuous platform scanning. Scope, timing, environments, test accounts, and reporting requirements are agreed for each engagement.
A reviewable record of security work
Reporting connects technical findings to ownership, remediation, verification, and the evidence a client security team needs to assess the control.
Security findings
A prioritized record of the affected asset, weakness, severity, supporting evidence, and recommended remediation.
Used for: Vulnerability review and remediation planning
Remediation history
Issue status, ownership, fix activity, pull request context, and rescan results provide a traceable path from detection to verification.
Used for: Customer diligence and internal accountability
Security and compliance reports
Exportable reports summarize security posture, detected risk, open and resolved findings, and available software inventory evidence such as SBOMs.
Used for: Audits, risk reviews, and compliance evidence
Platform audit trail
Administrative and security activity can be reviewed alongside Helium’s action logs and approval history.
Used for: Control testing and incident investigation
Evidence for FedRAMP and CMMC review
Regulated environments require more than a single assessment. Our operating model combines continuous vulnerability monitoring, controlled data boundaries, accountable remediation, and exportable evidence so security work remains current between reviews.
Authorization boundary
Deployment architecture, connected assets, data flows, external providers, and inherited controls are documented as part of the customer security review.
Important scope statement
These capabilities support FedRAMP and CMMC control implementation, continuous monitoring, and assessment evidence. They do not by themselves provide FedRAMP authorization or CMMC certification. Those outcomes depend on the complete system boundary, implementation, inherited controls, documentation, and assessor review.
Continuous vulnerability monitoring
Connected code, dependencies, containers, infrastructure definitions, cloud posture, virtual machines, and public attack surface are scanned as the environment changes, not only before an assessment.
Available evidence
Timestamped findings, affected assets, severity, scan history, and current remediation status.
Accountable remediation
Findings move into an owned workflow with prioritization, target dates, engineering context, fix activity, and rescanning.
Available evidence
Open-risk register, ownership, remediation milestones, risk decisions, and verified closure evidence.
Software supply chain evidence
Dependency, license, malware, outdated software, and container checks maintain visibility into the third party components used to build and operate the service.
Available evidence
Software bills of materials, dependency inventories, license findings, and vulnerability reports.
Boundary-aware scanning
Local scanning can be used for connected private repositories and container images where source code or artifacts must remain inside an approved boundary.
Available evidence
Scan output and remediation records without requiring protected source code to leave the controlled environment.
Access and action governance
Least privilege access, SSO and lifecycle management, human approval for sensitive actions, tenant isolation, encryption, and complete action traceability support regulated operating requirements.
Available evidence
Identity configuration, approval history, access scope, action logs, and encryption design evidence.
Audit ready reporting
Technical results are organized into reviewable reports that connect control operation to findings, owners, remediation, and verification.
Available evidence
Exportable security reports, audit logs, SBOMs, remediation history, and evidence suitable for GRC workflows.
Get authorized
Identify and remediate risk across code, infrastructure, and cloud systems before assessment. Document how controls operate inside the system boundary.
Prove controls on demand
Produce vulnerability reports, SBOMs, remediation records, approvals, and audit history without rebuilding evidence manually.
Stay authorized
Keep scanning and evidence current as code, dependencies, infrastructure, and externally exposed assets change.
Customer controlled processing boundaries
Helium runs locally first. Workflows execute on the device, then inside your environment, and only reach outside the perimeter when the approved workflow requires it. Even at that step, the host running Helium does not read your data.
Deployment architecture
Data follows an approved path
Customer boundary
Device
Local processing
Approved boundary
Environment
Scoped credentials
Explicitly allowed
External compute
Minimum payload
Identity
Who may act
Approval
What may happen
Audit
What did happen
- 01Default
On the device
The agent observes, decides, and acts on the device where the work already happens. Operational data is processed in place and never copied to a vendor environment.
- 02When the workflow needs it
Inside your environment
When a workflow needs a system you operate, Helium connects from inside your perimeter using credentials and permissions you scope, with the same access controls you already enforce.
- 03Only when you approve it
Approved external compute
When a workflow calls an approved language model provider or offload compute resource, the request travels encrypted, is scoped to the minimum payload, and is recorded in the audit log.
Encryption across data paths and storage
Customer data is protected in transit, at rest, and between Helium components. Keys, credentials, and execution context are scoped to the customer environment.
- L4
Application payloads
Sensitive payloads passed between Helium components use envelope encryption, so privileged infrastructure roles cannot read workflow content.
- L3
Secrets and credentials
Credentials for connected systems are stored in an encrypted vault, scoped to the agent that needs them, and rotated on a defined cadence.
- L2
Data at rest
Data persisted by Helium is encrypted with AES 256, with keys managed through your KMS or in a customer scoped key hierarchy.
- L1
Data in transit
All traffic between users, agents, and integrated systems travels over TLS 1.2 or higher, with strong cipher suites and certificate validation.
Identity, access, and accountability
Helium combines scoped permissions, identity lifecycle controls, human approval, audit records, data minimization, and tenant isolation.
Scoped access controls
Every agent operates with the minimum permissions required for its workflow, scoped by role, system, and action type.
Identity and SSO
Helium integrates with your identity provider through SSO and SCIM, so user access follows the same lifecycle process you already enforce.
Approval workflows
Sensitive actions can require human approval, with approvers configured by role, risk level, or system of record.
Full audit trail
Every agent action is logged with the inputs reviewed, the decision taken, and the resulting change, ready for export to your SIEM.
Data minimization
Helium reads only the data required for the approved workflow and discards intermediate context once the action is complete.
Tenant isolation
Customer environments are logically isolated end to end, with separate keys, separate storage, and separate execution context.
Data handling commitments
The commitments that guide how Helium handles operational data, applied consistently across deployments and reviewed during enterprise security assessments.
Compute runs on your devices and inside your environment by default.
The host running Helium cannot read your operational data, and neither can Agens.
Data leaves your perimeter only when an approved workflow calls a language model provider or offload compute resource.
When external compute is used, payloads are scoped to the minimum required, encrypted in transit, and never used to train external models.
Every agent action runs under your approvals, permissions, and audit log.
Review the controls and evidence with our team
We walk client security teams through deployment boundaries, encryption, identity, approvals, audit logging, scan coverage, remediation evidence, reporting, and commissioned penetration testing. Share your review framework and we will map the relevant controls and available evidence to it.