The End of Rented Security

Software-as-a-Service can give a team access to useful security capabilities without taking on the full burden of running them. The provider handles an agreed share of maintenance and operation, and the customer buys a service. That can be a sensible division of work.

The question changes when a platform becomes central to how an organization controls access, handles data, or responds to incidents. At that point, the buying decision needs to include what the customer can inspect, change, export, and continue operating if the relationship ends.

I believe those choices deserve the same attention as features and price. Owning a critical part of the system may be worth the additional responsibility, but that case has to be made for the particular organization.

A stack of individually useful products can still be difficult to operate. Teams may have to reconcile identities, translate alerts, copy evidence, and maintain integrations before anyone can make a decision. Adding another product can add another handoff.

Before replacing the stack, map that work. Identify which integrations support a necessary boundary and which merely bridge overlapping tools. Ask who maintains them and what happens when an integration stops working.

This makes the ownership discussion concrete. The goal is to reduce unnecessary coordination while preserving the controls the business needs, rather than to replace every hosted product with custom software.

License fees are only part of the decision. Include the effort required to adapt workflows to the platform, maintain integrations, train operators, and move data and policy elsewhere. A low initial price can coexist with an expensive exit.

Vendor dependence is not automatically a reason to reject a product. It is a reason to test the terms of that dependence: data export, service continuity, support, change notification, and the work required to replace the provider. Apply the same scrutiny to components used in a customer-owned system.

Ownership is too broad a word to serve as a requirement. Name the decisions your team needs to retain: where data is stored, who can access it, how keys are managed, which changes require review, and how activity can be inspected.

Some of those requirements may be met by a hosted service. Others may call for a customer-managed environment or a tailored integration. A private deployment still needs an explicit account of external model calls, support access, telemetry, and other paths that can cross its boundary.

If your organization has repeatedly replaced security platforms, examine why. Was the problem a changed business requirement, weak adoption, missing integration, cost, or a dependency the team did not anticipate? Those causes point to different remedies.

Customer ownership will not fix an unclear operating model. It may help when the recurring problem is an inability to adapt a critical component, but it also creates a system the organization must maintain. Use the history to define requirements, rather than assume that a new ownership model resolves every problem.

My preferred starting point is selective ownership: identify the parts of the security architecture where the ability to inspect, change, and continue operating the system matters most. Retain that control where its value justifies the work.

This can mean customer-owned software alongside hosted services. It can also mean choosing a hosted product with appropriate controls and a credible exit path. The principle is to make the boundary deliberate and keep the responsibilities visible.

Tutela by H2H offers AI runtime policy enforcement for connected agents, tools, and data in supported deployments. Teams can assess it when they need a defined product for controlling agent actions in an environment they manage. Its fit depends on the integrations and controls required for the workflow.

H2H also helps teams design and implement customer-owned systems when an existing product does not address the agreed requirements. That work starts with the workflow, access boundaries, deployment responsibilities, and criteria for accepting the result.

These are different decisions: whether a product fits, and whether a tailored implementation is justified. Neither should be selected simply because ownership sounds preferable.

A customer-owned system needs people, budget, and procedures for patching, monitoring, backups, recovery, capacity, and incident response. The agreement must also identify who supports integrations and who keeps the software compatible as dependencies change.

A team without that capacity may be better served by a hosted product or a clearly scoped support arrangement. Compare total operating cost and responsibility over the expected life of the system. Ownership is useful only if the organization can exercise the control it has acquired.

The useful next question is specific: which security decisions must remain under our control, and what are we prepared to run to retain that control? The answer should guide the architecture and the commercial agreement.

The end of rented security, as I see it, is the end of treating a subscription as the automatic answer. Hosted services can remain part of the system. What changes is the expectation that ownership, dependence, and operating responsibility are explicit choices.