Cryptographic Invisibility Locks Down AI-Built Apps

On June 9, 2026, Atsign put a sharper label on a problem security teams already feel: AI-built applications are being assembled faster than their identities, credentials, and service relationships can be reviewed.

The company’s new AI Architect platform applies what Atsign calls cryptographic invisibility to agentic software development, according to SecurityWeek. The pitch is not that bugs disappear. It’s that attackers should have far less to find, scan, map, or steal before they can turn a bug into a breach.

June 9: Why AI-built apps exposing identities became the security problem

AI coding tools have changed who can build software and how quickly it ships. That speed creates a hard security tradeoff. A developer, business analyst, or product team can ask an agent to generate an app, connect it to services, and push it toward production before a security team has manually checked every API, secret, service account, dependency, and permission path.

That matters because attackers don’t always start by cracking encryption. They start by finding things.

An exposed endpoint, a service identity, a token pattern, an API gateway, a DNS record, or a chatty log can give an attacker a map. Once the map exists, the attacker can probe for weak auth, vulnerable dependencies, overbroad permissions, or credentials left in the wrong place.

SecurityWeek frames Atsign’s argument around a long-running identity and visibility problem. In that framing, AI coding can weaken hard-won security discipline when apps are generated for speed and ease rather than security by design.

SecurityWeek also cites Broadband-Testing Ltd. on the risk that generative and agentic apps may be pushed into production before security is prioritized, especially in supply chain environments. The concern is that business pressure to capitalize on AI can outpace the controls normally expected around application delivery.

Atsign’s answer is to make application identities effectively invisible unless a party is authorized to interact with them. That is a serious claim, but it should be read carefully. Cryptographic invisibility does not remove the need for code review, access control, runtime monitoring, dependency checks, or incident response. It tries to shrink the visible surface attackers use before those controls even come into play.

Before the first trusted connection: What cryptographic invisibility means in AI Architect

In plain terms, cryptographic invisibility means an app, agent, or service should not have to expose a conventional network identity to the public internet before a trusted relationship exists.

That is different from common app design. Many applications expose some combination of public endpoints, API routes, gateways, service metadata, ports, credentials, or identity signals that can be scanned and stitched together. Even when the sensitive parts are protected, the outline of the system is often visible.

Atsign’s model starts from the opposite premise. Each resource gets a unique cryptographic identity. Interactions between resources are authenticated, authorized, encrypted, and governed by policy. SecurityWeek says Atsign’s existing approach secures human and non-human identities through advanced cryptology, with adversarial scans unable to recognize ciphercode “as anything, never mind an identity.”

That last part is the core idea. If an attacker cannot identify the app identity, credential path, or service relationship, a large class of opportunistic probing gets harder.

Here is the contrast:

This does not mean the software stops existing. It still communicates. It still runs code. It can still contain a bad dependency, flawed logic, or a prompt-injection weakness. The point is narrower and more useful: unauthorized parties should have much less visible surface to probe.

From blueprint to JSON prompts: How AI Architect tries to keep agents from advertising themselves

Atsign is not only selling a runtime security concept. SecurityWeek describes AI Architect as part of the build process for vibe coded apps, where developers use AI agents to generate software from high-level intent.

The workflow is presented as starting from a blueprint, or high-level description of what the app should do. AI Architect is described as using that intent, along with security rules and build guidance, to help produce JSON-based prompts and SDK references for AI-assisted development. The exact implementation details should still be validated during a pilot rather than assumed from the product description alone.

That framing is useful. Generated code is only one layer. The larger risk is that the agent builds a system with the wrong assumptions: too many open paths, unclear trust boundaries, excessive permissions, or dependencies that drag known vulnerabilities into production.

SecurityWeek presents the process as broadly compatible with the coding agent and LLM chosen by the developer. In this source, AI Architect is described as relying on mechanisms and policies that ensure every interaction between every resource is authenticated, authorized, encrypted, and governed by the context it provides.

That matters more for agentic applications than for static scripts. Agentic software may call APIs, hand off tasks, store data, interact with other agents, and make decisions without constant human supervision. Every one of those actions creates identity questions:

• Who is this agent?
• Which service is it allowed to call?
• What data can it access?
• When should access expire?
• How is the action logged and reviewed?

Atsign’s security advantage, if implemented as described, comes from minimizing exposed credentials and reachable endpoints while enforcing cryptographic identity between approved peers. SecurityWeek says no ports or public APIs remain open, and an attacker has nothing to scan.

XOOMAR analysis: that model directly addresses one failure mode of AI-generated software, insecure defaults that advertise too much. It does not solve every AI app risk. A compromised agent, malicious prompt, vulnerable package, or flawed business rule can still cause damage. The product’s real value will depend on key handling, policy enforcement, auditability, developer controls, and how well it plugs into existing security operations.

Deployment day: A fintech support agent under the old model and Atsign’s model

Take a concrete example. A fintech company deploys one AI support agent that performs three tasks: checks account status, opens service tickets, and talks to a payments system.

In a conventional deployment, that workflow can create a visible trail. The support agent may need an API token for the account system, a service account for the ticketing platform, and a connection to a payments interface. Logs may reveal routes. API gateways may expose patterns. Service names may leak through metadata. A bug in the generated workflow might not be catastrophic on its own, but the surrounding visibility gives attackers a path to test.

Under the model SecurityWeek describes, the agent and internal services would communicate through cryptographic identities. The support agent gets its own identity. The account service gets its own identity. The ticketing function gets its own identity. The payments connection gets its own identity. Only approved peers can discover and authenticate each other.

That changes the attack sequence.

The practical outcome is not magic. If the AI agent generates faulty payment logic, that logic still needs fixing. If a dependency is vulnerable, it still needs review. If the agent can be tricked into making a dangerous request, prompt-injection defenses still matter.

The difference is that random scanning and opportunistic probing become harder because the app is not advertising itself in the usual way. For teams already under pressure to patch quickly, that extra friction matters. It also connects to the broader push for faster remediation discipline, as seen in XOOMAR’s coverage of CISA's 72-Hour Patch Rule Puts Agencies on the Clock.

After agentic apps leave the lab: Where AI Architect fits in the security stack

AI Architect belongs in the same conversation as secure software development, secrets management, zero trust networking, API security, software supply chain controls, and AI governance.

It does not replace those categories. It pushes one control deeper into the build process: identity protection. Instead of waiting for generated code to expose an endpoint and then wrapping that endpoint in more controls, Atsign’s model tries to stop the app from becoming easily discoverable in the first place.

That is especially relevant for AI-built software because the build path is changing. Code can be generated quickly. Agents may act with partial autonomy. Business teams may assemble tools outside traditional engineering workflows. Security teams then inherit software whose architecture, permissions, and service relationships may be poorly documented.

Likely early adopters are the organizations with the lowest tolerance for exposed identities and uncontrolled agent behavior: financial services, healthcare, government contractors, SaaS providers, and companies building internal AI agents that touch sensitive data. That list follows from the product’s security posture, not from any deployment claims in the source.

XOOMAR analysis: AI Architect’s most useful role may be as a guardrail between intent and code. The blueprint stage can force teams to define purpose, boundaries, and behavior before a coding agent starts generating files. That is a better checkpoint than asking security to review a finished AI-built app after its architecture has already hardened.

Still, cryptographic invisibility should sit beside other controls:

• Secure coding: Generated code still needs review.
• Threat modeling: Teams still need to map abuse cases.
• Penetration testing: Hidden services still need hostile testing.
• Prompt-injection defenses: Agents still need protection from malicious instructions.
• Human approval: High-impact actions still need explicit gates.
• Patch discipline: Known vulnerabilities still need fast remediation, the same operational pressure XOOMAR covered in CISA's 72-Hour Patch Rule.

Security by design is strongest when it removes entire classes of exposure. It is weakest when buyers treat it as a reason to stop checking the rest.

Before buyers trust invisible software: Questions CISOs should force into the pilot

The first buyer question is simple: who controls the keys?

SecurityWeek says Atsign’s cryptographic keys are non-custodial, meaning they belong solely to the developer and cannot be stolen from Atsign’s relay servers. It also says that if an Atsign server is compromised, it can contain only ciphertext, not cleartext or credentials. That is an important design claim. Buyers should still test how it works under failure, recovery, and revocation.

Security teams should press on the operational details:

• Key control: Who creates, stores, rotates, and revokes cryptographic identities?
• Revocation: What happens when an agent, developer account, or service identity is compromised?
• Policy audit: Can teams prove which identity accessed which resource, when, and under what rule?
• Incident response: If services are intentionally hard to discover, how do defenders investigate abuse without weakening the model?
• Agent compromise: What prevents a valid but hijacked agent from misusing its approved access?
• Prompt attacks: How does the platform handle malicious prompts or indirect prompt injection?
• Dependencies: Can the workflow detect vulnerable open source packages pulled into generated code?
• Behavior drift: What happens when generated code behaves differently from the blueprint?
• Cloud fit: How does the model work across existing cloud, identity, logging, and SIEM tools?
• Compliance reporting: Can security teams produce evidence without exposing the identities the system is meant to hide?
• Disaster recovery: What breaks if keys are lost, policies are misconfigured, or relay infrastructure fails?

The hard balance is visibility for defenders without visibility for attackers. A platform built around invisibility has to give security teams enough telemetry to investigate, audit, and govern. If it reintroduces broad exposure to make operations easier, the model weakens. If it hides too much from defenders, incident response suffers.

The next decision point for buyers is not whether cryptographic invisibility sounds elegant. It does. The real test is a controlled pilot: build an AI-generated app, assign cryptographic identities, attempt unauthorized discovery, review logs, rotate keys, revoke access, and break the workflow on purpose.

If Atsign’s model holds up under that pressure, AI Architect could become a meaningful control for agentic application security. If the controls are opaque or hard to operate, it risks becoming another layer teams admire in architecture diagrams but work around in production.

Impact Analysis

• AI-built apps can reach production before identities, credentials, and permissions are fully reviewed.
• Attackers often begin by mapping exposed endpoints, tokens, APIs, and service relationships rather than breaking encryption.
• Atsign’s platform reflects a broader push to make AI-generated software harder to discover and exploit by default.