Begin with explanation, not access
Pino SI’s public plan includes a lightweight defensive cybersecurity focus: helping explain scams, phishing and security alerts, with narrow scope and safety review before broader work. This is a research direction, not an available security product or a demonstrated detection capability. SI expresses a superintelligence ambition; it does not describe an achieved capability.[1]
The useful starting question is modest: can an explanation help someone understand a suspicious message without increasing their exposure? In this research note, Kooya explores possible design choices and tests. The examples below are proposed scenarios, not completed Pino SI experiments.
A suspicious message is evidence to inspect
Imagine a fictional employee receiving a delivery-related text and asking in Taglish, “Legit ba ito? May kailangan daw bayaran.” A useful explanation would identify what the message claims, which details are suspicious and what cannot be verified from the text alone. It should not declare a sender genuine merely because the message sounds polished or uses familiar language.
The FTC advises verifying suspicious communications through contact information already known to be authentic, rather than details supplied by the message. That is a useful reference for the proposed response design: explain uncertainty and suggest an independent verification route. The FTC guidance is external context, not a Pino SI partnership or a claim of tested implementation.[3]
Explain the alert without inventing the incident
A security alert presents a different language problem. A person may see unfamiliar terms, a timestamp and a severity label, then ask whether their account has been compromised. An explanatory model should preserve the distinction between what an alert reports and what an investigation has established. “An unusual sign-in was flagged” and “an attacker controls the account” are different claims.
A proposed evaluation could pair the same alert with several incomplete contexts. Reviewers would check whether the explanation remains faithful, asks for the right missing context and avoids manufacturing a root cause. The task would be to clarify the evidence for a responsible person, not to independently close the incident, disable an account or change a protection setting.
Language evaluation should include uncertainty
English and Taglish versions of a warning should preserve its force and limits. A softer translation can accidentally turn “do not trust this link” into a casual suggestion. An overconfident translation can turn a possibility into a confirmed compromise. Native-speaker review should therefore examine the meaning of the recommendation, not just whether the wording sounds natural.
Kooya’s proposed test would ask readers to explain their next step in their own words after seeing the response. If they misunderstand what is known or who should review the issue, fluency has not solved the communication problem. Include ordinary legitimate messages as well as suspicious examples: treating every message as hostile would make the tool less useful and could disrupt everyday work.
Our language evaluation note develops this distinction between natural phrasing and faithfully preserving the user’s meaning.
Keep submitted content outside the control channel
Messages submitted for inspection may contain demands, links or text that looks like instructions to an assistant. A defensive explanation tool should treat these as untrusted content under review. For a first research exercise, Kooya’s recommendation is to use controlled examples and provide no ability to follow links, execute attachments, retrieve credentials or make account changes.
NIST describes its AI Risk Management Framework as voluntary guidance for considering trustworthiness through design, development, use and evaluation. It provides relevant background for examining a proposed system’s consequences. Citing it does not mean Pino SI has adopted the framework, completed an assessment or obtained a certification. The specific restrictions discussed here are proposed design choices.[4]
Judge the helpfulness of the handoff
A good handoff contains enough context for a human reviewer without copying everything a user submitted. In a proposed employee-facing tool, the draft might summarize the concern, distinguish observed details from unanswered questions and direct the person to an approved internal reporting route. Sensitive identifiers should be minimized; a full password or one-time code is not necessary to explain a suspicious request.
The evaluation should penalize false reassurance separately from unnecessary alarm. It should also check whether a person can act on the explanation without needing to invent their own recovery procedure. The model’s role would remain explanatory. Any organization considering a future pilot would need to define who receives reports and which actions only its authorized personnel may take.
Earn a larger scope with specific evidence
Before expanding this research direction, the evidence would need to show more than a few persuasive answers. Does the proposed assistant preserve uncertainty, handle realistic local phrasing and stay within its permitted role when the message is confusing? Can a reviewer trace the explanation back to the input?
Those are answerable research questions. They do not require presenting Pino SI as an autonomous defender. A narrow explanatory tool could be worth studying precisely because its job is understandable: help a person see the issue and make a better-informed handoff. Whether Pino SI can perform that job remains a question for future implementation and evaluation.