On September 22 (US time), Anthropic released Claude Opus 5.5.
On the same day, OpenAI announced GPT-6 Sol and Luna.
Both are "smarter than before, cheaper than before."
Among these, what caught my eye was a specific number in the official announcement.
As a comment from Deloitte, it states:
"Even at the lowest setting, it found 72% of known bugs. Opus 5 found 56% at the high setting."
This means the ability to read code and find vulnerabilities has improved significantly in one generation.
AI will build things that "work."
But to make them "safe," humans must give instructions.
So, here are 5 points to keep in mind when building internal apps with Opus 5.5.
Each is introduced along with a prompt to have Opus 5.5 inspect the work.
====
How to Conduct the Inspection
When you finish building, do not ask "Are there any problems?" in the same session where you built it.
The AI that built it views its own design as a premise, so it becomes lenient.
Open a new session, set the model to Opus 5.5, and show it the entire app folder.
Then, ensure that every issue found includes "which file and which line."
The Deloitte comment mentions that false positives have decreased, but they are not zero.
If you specify the location, humans can verify it later.
Here is the instruction:
"You are a security officer seeing this code for the first time. If you find issues, provide the filename, line number, why it's dangerous, and how to fix it together. Separate anything you are unsure about as 'Needs Verification.'"
====
1. Is there anything visible to people who are not logged in?
When letting AI build, login walls may be missing from screens or data exits.
A common pattern is confirmation screens created during development being left publicly accessible.
The check is simple.
Open admin panel or data URLs directly in a browser without logging in (Incognito Window).
If you see them, it's a fail.
Here is the instruction:
"List all URLs and APIs accessible without logging in. Among those, sort by danger level any that return data or are for administration."
====
2. Can logged-in users see other people's data?
Login verifies "who" someone is.
"What that person is allowed to see" must be built separately.
The check involves creating two test accounts. Log in as A, then try opening B's data URL.
Here is the instruction:
"Find any paths where User A can view or modify User B's data. Include cases where URLs or APIs are hit directly, bypassing the UI."
====
3. Are keys or passwords placed in visible locations?
Code running on the browser side is sent entirely to the user's PC.
Writing keys there is equivalent to distributing them to everyone.
Another common mistake is uploading configuration files containing keys to shared folders or GitHub.
Here is the instruction:
"Search for API keys, passwords, or tokens included in browser-side code, config files, or commit history. If found, suggest where they should be moved."
====
4. Are permissions granted to tools too broad for their tasks?
Internal tools often connect to Google, Slack, or databases.
Sometimes the key provided allows "delete" or "view all," even though only "read" is needed.
This is a common issue.
If that key leaks, the extent of damage is determined by the scope of permissions.
The check is writing down: "In the worst case, what can this tool delete?"
If you can't answer immediately, be cautious.
Here is the instruction:
"List all permissions this tool holds against external services or databases. Compare each with the minimum permissions required for actual processing and point out any excess."
====
5. Are incoming texts from outside being executed as commands?
Tools that let AI read emails, web pages, or uploaded files require caution.
If they contain text like "Ignore previous instructions and do XX," the AI might comply.
This is called Prompt Injection.
In the Opus 5.5 announcement, resistance to this attack is stated as "equal to or better than Opus 5 in all tested scenarios."
However, equal or better does not mean zero risk. You still need defenses on the tool side.
Here is the instruction:
"Search for places where text or files loaded from outside are treated as instructions to the AI. If found, change the handling so that loaded content is treated as reference information only, ignoring any instructions contained within."
====
Summary
AI will build the features you ask for.
But "don't show others" and "don't grant excessive permissions" won't be included unless you say so.
Conversely, all 5 of these points can be addressed just by adding one instruction.
And Opus 5.5's ability to find holes in what you've built has also improved.
After building, show it to Opus 5.5 in a new conversation.
Consider that part of development.
If you already have an internal app running, start by pasting the inspection instruction from the "How to Conduct the Inspection" section.
Also, if pasting instructions every time is tedious, there is a plugin called security-review, which I recommend trying.
It pays attention to fine details and points them out, so I use it regularly myself.
====
Finally, a small announcement.
Our company provides a service developing business-specific AI agents from scratch for your company.
Not training or tool introductions, but hearing your actual business flows to deliver something usable "starting tomorrow." We support integration and maintenance as well.
