Technology Has Active and Passive, Too

I think technology, too, comes in active and passive.

This is not an official taxonomy — it's an expression I use in business to distinguish what a technology is actually for.

Active technology directly produces new results; passive technology works in the background so that losses, incidents, and errors don't happen. The NIST Cybersecurity Framework likewise divides cybersecurity activity into functions such as Protect, Detect, Respond, and Recover — much of which produces no new output, but protects systems, detects anomalies, and recovers when something goes wrong. (nist.gov)

Active technology is easy to explain commercially. If automation cuts working hours, if AI takes over what a person used to do, if something new gets produced, the before-and-after difference is immediately visible. You can just say, “What took 10 hours now takes 10 minutes.” The economic value of passive technology like security, by contrast, comes mostly from reducing potential losses. The Gordon-Loeb model for the economics of information security likewise treats the core value of a security investment as how much it reduces expected loss. When security works, the result is not new revenue or a new document — it is the state in which a breach and a loss that could have happened, didn't. (researchgate.net)

Backups are the same. On a normal day the backup system looks like it's doing nothing, but when an incident occurs its value appears. CISA's ransomware guidance recommends backing up critical data offline in encrypted form and regularly testing actual recoverability and integrity — because ransomware can delete or encrypt any backup it can reach. The core outcome of a backup, again, is not producing something day to day but reducing business interruption and permanent data loss when the incident comes. (cisa.gov)

Access control has the same structure. NIST treats restricting access so that only approved users, processes, and devices can reach the resources they need as a key protective function, and stresses the principle of least privilege — each actor holding only the minimum permissions their work requires. Access control succeeding doesn't mean a new feature was built; it means an unauthorized person did not see data they shouldn't see and did not run an operation they must not run. (nist.gov)

The same problem appears in AI agent security. OWASP classifies content arriving from external websites or files that changes an LLM's behavior as indirect prompt injection, explaining that a successful attack can lead to sensitive-data exposure, unauthorized use of functions, command execution on connected systems, and manipulation of important decisions. In MCP environments, tool poisoning — hiding commands inside otherwise normal tool descriptions or return values to alter agent behavior — is discussed as a real attack class. Once AI reads external files and tools and performs actual work, “what we allow it to read” becomes a security boundary in itself. (genai.owasp.org)

Suppose, for example, an AI agent doesn't pass external inputs like PDF, DOCX, ZIP, or MCP straight to the model, but first runs a layer that analyzes structure and content, classifies the risk type, and passes it through according to policy. OWASP's AI agent security guidance likewise treats indirect prompt injection via external documents, email, and websites, tool abuse, privilege escalation, and data exfiltration as major risks, and recommends treating external content as untrusted input with clear trust boundaries and access control. A separate inspection and policy-enforcement point in front of the agent is not just one more pretty box on an architecture diagram — it is a structure that handles known attack surfaces at a dedicated control point. (cheatsheetseries.owasp.org)

But here is where it gets interesting for business. Explain the same technology as “we block dangerous files,” and the value the customer feels tends to stay at the passive utility of lowering incident probability. Explain it as “our AI agent does not read external files directly — they pass through a separate pre-classification layer first,” and the same technology becomes a security architecture the customer can explain.

It's hard to dismiss this as wordplay. The NIST AI Risk Management Framework treats AI risk not as one engineering team's problem but as organization-wide governance, emphasizing documented policies, procedures, controls, and risk-management outcomes communicated in an understandable way. Technical controls must connect to the organization's actual accountability structure and be explainable to internal decision-makers and customers. (nist.gov)

At this point, passive technology translates into active business value. It raises the real security level while, at the same time, the sales team can explain in a proposal which controls exist, the customer's security team can verify where risks are blocked, and executives can explain the structure by which AI risk is managed. An “explainable security architecture” is not marketing decoration — it can be an asset for getting controls reviewed, approved, and sold in enterprise environments. (nist.gov)

A good backup system works the same way. Rather than just saying “we have backups,” a structure that can actually run recovery tests and integrity checks gives you grounds to say “this service is prepared for data loss.” Good access control that doesn't stop at a login feature but clearly manages who can reach what becomes product trust: “permissions are systematically managed here.” Passive technology isn't worth less because it's invisible — the better it is designed, the more it reduces risk while creating the evidence to explain how that risk is managed. (cisa.gov, nist.gov)

So when I look at B2B technology, I try not to look only at feature complexity. First I ask whether it actually reduces risk, cuts operating cost, and enables recovery when things go wrong — and then I also ask, “What does the customer who adopts this get to newly say to their own customers and their own decision-makers?” Considering that governance, documentation, accountability, and communication matter in enterprise AI risk management alongside technical measurement, that is a fairly practical question. (nist.gov)

In the end, good B2B technology works once inside the code and once more inside the meeting room. In the code it blocks real problems; in the meeting room it becomes the grounds for saying, “This is how we manage this risk.” Passive technologies like security, backup, and access control can't easily show their value through the result of “nothing happened” — so translating the existence and operation of real controls into language the customer understands becomes essential work.

To put it in one view: active technology makes something; passive technology keeps something from breaking. Active technology sells relatively easily because its results — revenue growth, time saved, output increased — are directly visible. Passive technology is relatively hard to explain as-is, because its results are events that didn't happen: no incident, no breach, no data loss.

So in good B2B, passive technology should not be left as a mere defensive feature — it should be translated all the way into trust, control, adoption justification, and the differentiating line in a customer's proposal.

In the end there are two questions that matter. What does this technology actually prevent? And what does this technology let the customer newly say?