OPEN ARCHITECTURE / 3 OCTOBER 2026
Security you can understand.
A local approval boundary for the software and AI tools you choose to trust.
01 / The problem and our approach
A valid identity and a trusted device do not establish that every action is appropriate. A coding tool may receive broad permissions, load unreviewed instructions, reach a deployment command or encounter a credential in a repository. Permission to use a tool is different from approval to make a particular production change.
AppoSlash provides a small, inspectable preparation step: select supported source or configuration, place it in a local approval queue, approve the review, and read evidence with practical next steps. It also makes bounded public website observations and receives signed website-event indicators when an owner connects an event source.
This release is a static assessor. It does not intercept another AI agent's live session, discover every AI asset on a computer, test passwords, run submitted software, or guarantee protection from compromise. A match is an indicator for review; no matches do not prove an asset is safe.
Our design goal is useful friction at the point of trust: make scope and permissions visible, keep the person in charge, and help a non-specialist identify the next sensible action. The friendly guardian and blossoms are a visual language for calm and care, not a security certification.
02 / The local approval workflow
The desktop edition includes its own Python runtime and required libraries. A Windows user installs it for their own account, receives Desktop and Start-menu shortcuts, then creates a private sign-in. It opens a loopback browser workspace; it is not a background antivirus service or a native scanning dashboard.
The workspace stores accounts, scopes, pending requests, reports and audit events in local SQLite storage. Selected source is encrypted while awaiting review. The encryption key remains in the user's private local configuration. A person or process able to read both that key and the database can decrypt the stored material; encryption is not isolation from a fully compromised Windows account.
Submission clients can queue supported source but cannot approve an analysis. Owner approval is required before static analysis starts. The reader handles bounded ZIP archives and supported UTF-8 text. It checks file locations for possible credentials, deployment commands, server access, AI skills, MCP configuration and broad permission settings. It does not execute the submitted code or test whether a credential works.
Reports omit source excerpts and credential values. Operators review findings before acting. Client revocation, session revocation, organization isolation and CSRF checks provide distinct boundaries around submission, account access and owner actions. Backups before migration and preservation of existing keys/accounts are part of setup.
03 / Website reviews, alerts and permissions
The free local website reviewer performs fixed, bounded reads of public pages without ownership proof. Observations can include HTTPS behavior and browser-response protections. These public observations are configuration indicators, not exploit tests, authenticated application audits or a whole-site safety score.
Deeper assessment requires fresh ownership proof, approved exact-host scope and configured capabilities. Request budgets, cancellation, private-address blocking and redirect validation constrain network activity. Authorization for one hostname does not grant authorization for other hosts or production changes.
Website incident alerts require a connected signed event source. The receiver checks ownership, exact host, HMAC signature, event timestamp and replay protection. A suspicious indicator is not itself proof that a website has been hacked. This release does not magically observe every attack on an unconnected site.
Audit-request and result notices work while a signed-in local workspace remains open. Browser notifications require an explicit user click and browser permission. Optional website email requires configured SMTP. Alerts are not guaranteed when the browser or local server is closed, offline or prevented from delivering notifications. The permissions page shows clients, sign-ins, pending requests and monitoring configuration so the owner can review access.
04 / Examples and the threat model
An AI settings file contains approval_policy = never. AppoSlash can identify the pattern and its location. It cannot conclude that the setting is active in another program or that a session has already performed an unauthorized action. The next step is to review the setting and actual permissions in the owning tool.
A release script contains vercel --prod or an SSH command. The reader can point out the deployment or access path for review. It does not run the command, contact the server, verify the credential or approve a production release. The owner can then constrain environments and require separate deployment approval.
A text shortcut contains an active-code URL, or a database script contains a destructive statement. These are review indicators; the content is not opened or executed. Ordinary greetings or placeholder credentials can also occur in safe examples. Context and false positives require human judgement.
Primary boundaries address unauthorized submission access, premature analysis, cross-workspace access, accidental secret exposure in reports, malicious archives, unbounded network requests and forged website events. The release does not defend against every local administrator, stolen operating-system credentials, kernel compromise, malicious installed binaries, unknown attacks or a hostile provider. Media content and installed executable applications are not malware-scanned.
05 / Evidence, limitations and release quality
The assessment core passed 257 Python checks and three JavaScript notification checks on controlled fixtures before this desktop edition. Those checks exercise ownership and scope, network limits, isolation, signature/replay validation, source approval, report redaction, notifications and migrations. They establish behavior on those cases, not a measured real-world detection rate.
The new Windows binary is exercised in an isolated folder: extraction, bundled runtime, storage preparation, account creation, key/account preservation, loopback startup, login availability, duplicate-start handling, matching-instance stop and a generated test shortcut. The installer includes dependencies instead of asking the user to install Python. The graphical wizard is not automatically exercised by these binary smoke checks.
The public website provides harmless browser-only examples. Demo text is not uploaded, saved or executed. Its pattern set is deliberately smaller than the local reader. Publication checks establish that metadata, guides and downloads respond; they do not establish security or search ranking.
Historical homepage observations of AppOpener .com and .in motivated stricter checks for incomplete browser policies. They are dated configuration observations, not evidence of exploitation or a current comprehensive assessment. Native Mac/Linux installation, production SMTP delivery and live AI-session interception are not validated. The Windows executable is not code-signed by a verified publisher in this release.
06 / Commerce, transparency and next steps
The proposed price is INR 999 for the Windows desktop installer, paid once. It does not buy a promise of invincibility, an antivirus subscription, continuous monitoring, an included custom audit service or unlimited future releases. Source review and the separate legacy assessment packages are distinct from this download purchase.
The Cashfree integration follows AppOpener's server-owned order approach: a fixed INR amount, provider idempotency, exact order/customer checks and fresh server-side payment verification. A browser return or checkout callback cannot unlock a download. Successful or pending refunds block a newly issued download grant. A short-lived signed cookie protects the desktop artifact through Vercel routing middleware; already downloaded software cannot be remotely recalled.
Cashfree holds payment order records. The website uses signed, HttpOnly order cookies and does not claim a durable merchant ledger of its own. A saved recovery code is a bearer secret: keep it private. It expires after 30 days and payment/refund status is rechecked before a new download. No charges can start unless production credentials, a signing secret, the approved website domain and explicit checkout enablement are configured. This publication does not establish merchant approval or a successful real-money transaction.
Visitors can read this paper, try examples and inspect published setup notes without payment. Optional cryptocurrency support displays an address only; it does not choose a network or initiate a transaction. Support for installation or payment issues is contactus@appopener.com. Future work should prioritize representative labelled cases, measured false positives, independently reviewed releases, publisher signing and tested platform support before expanding protection claims.
References
