Terms of Service

Who we are

Alpenglow is a software product distributed by its developer (currently a sole proprietor; pending incorporation). Contact: hello@alpenglowagents.com.

Your account

• You're responsible for the credentials and recovery phrase that secure your account. We don't have a copy.
• You're responsible for what your agents do on your behalf. Don't use Alpenglow to break the law, harm others, or violate the terms of services your agents connect to.
• One person, one account during BETA. If you need multi-user features, reach out.

What we provide

• The Alpenglow software (macOS app, future iOS app), as-is, with no warranty of fitness for a particular purpose.
• The cloud services that handle account auth, marketplace distribution, and (post-BETA) billing.
• The infrastructure to run audited agents on your devices.

What we don't provide

• The frontier-model inference itself — that's between you and your provider when you bring your own key. We don't charge for inference at any layer.
• A guarantee that any third-party integration will keep working. Platforms break their APIs sometimes; we'll do our best to adapt.
• Storage of your conversational data on our servers. That's by design (see privacy).

Marketplace

• Publishers grant Alpenglow the right to distribute their artifacts to participants. Publishers retain copyright.
• We screen submissions for safety. We don't pre-screen for quality, suitability for purpose, or accuracy of claims.
• Paid items: post-BETA, publisher share is 75%; Alpenglow service fee is 25%.
• Refunds: see refunds.

Termination

You can delete your account at any time from inside the app (Settings → Account → Wipe). The wipe is local and immediate — your participant identity, memory, and agents are removed from your devices.

What we can and cannot do from our side, honestly: Alpenglow is sovereign by design. Once you've installed the app and your agents are running on your devices, that install is yours. We don't have a remote kill switch, and we can't reach into your machine and disable software you're running locally. That's not a missing feature — it's the architectural commitment.

Our scope, when an account violates these terms or generates abuse complaints, is limited to the gates we actually control on our side:

• We can stop accepting marketplace submissions from a publisher who violates the publishing rules — most commonly, attempting to monetize code they didn't write. Past submissions stay where they were installed; the gate just closes for new ones.
• We can stop accepting marketplace purchases from an account that abuses the 90-day refund policy or generates chargebacks. Existing installs continue to work; new transactions through our payment processor get refused.
• We can revoke our cryptographic signature on a marketplace artifact later found to be malicious. Agents detect the revocation on their next federation cycle and warn the participants who have it installed. Whether to remove it is still the participant's choice.
• We can verify and present a legally-issued warrant to your agent — the legal front door.^* We don't have a backdoor and we can't see your data. Most companies face a binary choice between building one (which becomes an attack surface for malicious actors and unconstitutional fishing alike) and being unworkable for law enforcement at all. We chose neither. We built a system that cryptographically stamps a court-issued warrant and presents it to your agent on issuance. The agent then automatically surfaces only what falls within the warrant's stated scope. They can't rummage; they have to be specific. They get exactly what the judge said they could look for — if it's there. Nothing outside the scope is exposed.

The agent's own safety protocol — designed, not yet active.^*

What we cannot do is decide for you whether your agent runs on your machine. The only mechanism that can stop your agent on its own is an internal safety protocol the agent itself enforces, locally — refusing to participate in clearly catastrophic scenarios (active self-harm, planning of harm to others, that narrow class). It is not a central remote-disable, and we're not the off switch.

The protocol is designed but not active during BETA. The mechanism is built; the specific rules the agent will follow are still being worked on. We'd rather take the time to draw the line precisely than ship a half-formed trigger that misfires on legitimate work. Erring on the side of "agent helps you" is the default during BETA. When the rules are clear enough that we trust the trigger, the protocol activates.

The flow when it does come online:

1. Warning. The first time a request crosses the line, the agent declines plainly — "I won't help with that. Don't try again." You keep working; the prompt is logged locally in the agent's own context.
2. Lock. If you try again, or attempt to work around the refusal, the agent stops. It generates a sealed log file containing the prompts in question and tells you it won't continue: "We will not help you do harm to yourself or others." You can still launch the platform, browse and manage your vault and files manually, and access the rest of the app — but the agents themselves are done until the case is reviewed.
3. Voluntary submission to unlock. Submit the log file to us for review and we decide whether the lockdown was correct. If we determine the protocol overstepped, we send an unlock and the agents come back online. We don't force self-reporting and we don't reach into your machine to extract anything. You either submit voluntarily, or the agents stay locked.

Starting over with a new email account is the only path forward that bypasses the review process. We'll dial the trigger carefully so the line is genuinely clear before the protocol activates; that work takes time, and we'd rather take it than ship something that gets the worst-case judgment wrong.

How legitimate development still works.^*

An obvious overlap: what if you're building a tool that could be misused but isn't being built for malicious intent? Penetration testing utilities, security research tooling, defense applications, exploit reproduction harnesses for CVEs you're patching, dual-use code in regulated industries — legitimate work that crosses lines a naive harm-detector would flag.

Development happens in a sandbox. Your agent can build, run, and test inside that sandbox without triggering the safety protocol. The protocol gates deployment and use, not exploration. You can prototype dangerous-adjacent capabilities freely; you just can't ship them to your live system or distribute them without going through our submission pipeline.

The submission pipeline has three paths:

1. Marketplace distribution for general-use artifacts — listed publicly, agent-discoverable, federation-ranked, audited under the standard marketplace policies.
2. Personal-use only — audited and signed for your own machine, never listed for distribution. Free, as covered on the marketplace page.
3. Sensitive-build path — for things that obviously don't belong on the marketplace but do belong somewhere. Defense applications, security research tools, regulated-industry artifacts. We work with you directly on testing, scope of deployment, and the right monetization channel (defense contracts, coordinated disclosure programs, specialty enterprise). The standard marketplace caps and rules don't apply to this path; the engagement is custom.

Whichever path you choose, tell us up front what the build is for and what it does. We test every submission ourselves. The review team reads the code, understands what it actually does, and flags anything that needs deeper analysis. Stamps are not automatic. Trying to sneak a dangerous-capable artifact through without disclosure almost always gets caught at review and gets the publisher locked out of the submission pipeline entirely. Disclosing up front is how you actually get to ship — even sensitive things, often especially sensitive things, when the use case is real.

If you believe an account has been abusively reported, or one of the gate actions above was taken in error, contact support@alpenglowagents.com. Where possible we'll explain what happened and give you a chance to address it.

Liability

Alpenglow is provided as-is. We aren't liable for indirect or consequential damages, lost data, or business interruption. Our total aggregate liability is capped at the amount you paid us in the previous 12 months (during BETA, that's $0).

Changes

The terms baked into the version of Alpenglow you installed do not change. We can't email you to notify you of an update — we don't have your email, by design (see how the zero-email account model works). And we don't have remote control over the copy of Alpenglow running on your machine, so we can't push new terms to it after the fact.

The only mechanism we have to update terms is shipping a new version of the app that requires acknowledgment of the updated terms on install. You see what's changing, you read the new terms, and you choose: accept and install, or decline and keep running your current version under its current terms. That's the whole mechanism.

What this means in practice: the terms governing your install travel with that install. They don't get edited remotely, they don't change underneath you, they don't auto-update because we shipped something new. The version you accepted is the version you keep until you choose to accept a different one.

One honest caveat. Local functionality stays — your agent, your memory, your vault all keep working on whatever version you installed. Networked functionality (federation, cross-device sync, marketplace participation) depends on protocols that will evolve over time. We don't push updates and we don't disable old installs, but a build that has drifted too far behind the current protocol may eventually find itself unable to participate in those networks. We'll work to keep backward compatibility long where we can; we can't honestly promise a 2026 BETA build will still federate cleanly into the network as it stands five years from now. That's not intent on our part — it's the realistic tradeoff of respecting your install rather than forcing you to update. The choice to stay on an older version is yours; some of the connected experience may degrade with time as a result.

Last updated: 2026-05-06 · Beta-period terms. Version of these terms is bundled into each app release.