01 / Grants
Grant applications
Teams need language that ties technical risk reduction to why the project deserves funding or infrastructure credits.
Use this route when funding narrative mattersPre-release cohort / grants / activations
Apply early for grant support and launch activations before general release.
This version is for teams that want to evaluate Bindfort ahead of launch, apply for early grant support, or line up joint activation work around secure MCP rollouts. No self-serve signup yet; access is reviewed directly.
Founding cohort access. Reviewed directly with the team.Grant-ready positioning. Clear security narrative for applications.Activation support. Built for pilots, showcases, and launch programs.
$bindfort up --config pilot.yaml
[ok] pilot gateway profile loaded / security controls enabled
[ok] architecture review checklist prepared for onboarding
[ok] receipt and audit paths ready for evaluation
$bindfort plan --program prerelease
-> preparing cohort notes, activation goals, and review items...
[warn] launch timeline depends on deployment target and review scope
[warn] partner activation requested / grant narrative needed
[ok] application packet can be completed with current architecture details
[ok] team review requested / next response within one business day
$
What the pre-release is optimized for
2
entry paths
grant application support and activation planning
1
review loop
direct evaluation with the founding team
4
supported transports
stdio, SSE, HTTP, and WebSocket pilots
0
pricing gates
review first, commercial terms later
Section 01 / Why pre-release
"Early infrastructure programs live or die on clarity. You need a product story, a deployment story, and a security story that all agree before you ask for funding or partner attention."
This pre-release page is for that moment: before broad launch, when teams need a credible security narrative for grants, activations, and early design partnerships.
Section 02 / What you are applying to
The same security core, packaged for an early cohort
The product stays technical. The difference is the motion around it: tighter review, earlier feedback, and support for programs that need a launchable security story.
Supply-chain scanner
The current scanner work focuses on installed-tree evidence and reachability during guided evaluation. Production CVE response, live blocking, alert routing, and exception workflows are v1.0 roadmap packaging.
Installed-tree evidence
Sandboxed execution
Isolation hardening is the product direction: run untrusted MCP servers with scoped filesystem, network, and process access. First-user packaging still needs a clean deployment profile.
seccomp / cgroups / namespaces
Description poisoning
Pattern-matches documented prompt-injection vectors in tool descriptions before they reach your agent's context window. Blocks the class of attack that jailbreaks the LLM, not just the network.
10+ attack variants
Rugpull detection
SHA-256 binary hashes are bound at registration time. Any silent update - the classic supply-chain rugpull - triggers immediate quarantine and a signed alert to your SIEM.
sha256 binding
Signed proof-of-execution
Current receipt evidence records inputs, outputs, timestamps, HMAC, and server fingerprint fields for guided inspection. The shipped bindfort verify command recomputes the HMAC chain and fails on tampering.
hmac chain / bindfort verify
Compliance-ready audit
Tamper-evident audit records chain tool-call evidence with cryptographic linking. The current local path supports verification; SIEM exports and formal control mappings remain roadmap packaging work.
EU AI Act evidence / SIEM roadmap
The goal of pre-release is not a waitlist.
It is a clean path from interest to a credible pilot.
Why this second landing page exists
Section 03 / Program fit
Built for teams that need more than a signup form.
If you are applying for infrastructure grants, lining up a partner activation, or preparing a launch cohort, the conversation is different from normal product marketing. This page speaks to that path directly.
Typical waitlist page
Interest capture only
- Collects emails without qualifying the deployment.
- Offers little help for grants or partnership review.
- Leaves the security story vague until later.
- Assumes self-serve onboarding exists already.
- Makes pricing the next step before fit is clear.
- Does not help a team justify early adoption internally.
Pre-release page
Review, narrative, activation
- Frames the product around an actual pilot path.
- Supports grant and activation applications with concrete language.
- Keeps the security story central from the first read.
- Routes interest into direct technical review.
- Removes pricing until scope and timing are understood.
- Sets expectations for a guided early rollout.
How the pre-release conversation usually starts
Your agents
Your target deployment and program goals
->
Bindfort gateway
Bindfort review / pilot design / activation planning
->
MCP servers
Pre-release access, grant narrative, launch support
The technical product remains the same. What changes here is the call to action: apply, review, and shape the launch motion before general availability.
Section 04 / Program tracks
Three reasons teams reach for the pre-release page
Keep the structure familiar, but make the path explicit: why are they here, and what do they want help unlocking?
02 / Activations
Partner or launch activations
A good activation page explains the product clearly enough that a partner can see the pilot shape without a long backend implementation story.
Use this route when launch coordination matters03 / Design partners
Early cohort evaluation
Some teams want access before release, but they also need the process, review criteria, and expected next step to feel real.
Use this route when direct review matters04 / Internal approval
Security review
Even an early product needs a page that helps internal champions explain why a pilot is worth the effort.
Use this route when internal buy-in mattersSection 05 / FAQ
Questions early-stage applicants
actually ask
Is this a product page or an application page?Positioning
Both, but weighted toward application. It explains the product enough to establish credibility, then routes interested teams into a reviewed pre-release path instead of a pricing or checkout flow.
Why is pricing missing here?Design partner
Because this version is meant for grants, activations, and pre-release review. Those conversations usually need fit, timing, and deployment scope clarified before commercial terms matter.
What should I send with an application?Design partner
Your MCP use case, target deployment environment, any grant or activation deadline, and what you want from the pre-release process: pilot access, architecture review, program language, or launch support.
Can this still turn into a paid pilot later?Design partner
Yes. The point of removing pricing here is sequencing, not avoiding commercial work. Once the evaluation path is clear, this can move into the normal product process.
Do I need to integrate a backend first?Verified locally
No. This route is designed for teams that are still evaluating fit, lining up sponsorship, or preparing a partner program. Direct technical review comes before heavy implementation.
Can I still see the standard product page?Positioning
Yes. Use the Product link in the top navigation if you want the standard commercial landing page with pricing included.
Pre-release applications / grants / activation support
Apply before launch
with the right narrative in place.
Use this route when you need a reviewed path into the product, help framing the security story, or support for a grant or activation deadline.
What we review with you
Whether the deployment and security story fit your grant or activation goal.
What a realistic pilot or cohort rollout looks like before general release.
Which assets, language, and milestones you need for the next step.
Include any grant deadline, activation window, or target launch date in the first message so review can be prioritized appropriately.