Act Security Launches With $60M for Action-Centric Cloud Defense

Corma did not launch with $60 million for defensive cybersecurity AI, despite a Google News headline that presented that claim as fact. The linked reporting instead describes Act Security, a different company that emerged from stealth with $60 million and a cloud security platform.

That distinction changes the story. Corma develops software access, identity governance, and license management tools from Paris. Act Security focuses on reducing dangerous cloud permissions before human attackers or AI agents can exploit them.

The error also exposes a larger problem for readers, publishers, and automated research systems. A plausible headline can combine the wrong company with a real funding event, then travel through an aggregation feed without enough context to reveal the mismatch.

The underlying Act Security announcement remains significant. Its platform challenges an established security model built around finding vulnerabilities, generating alerts, and asking teams to prioritize the results. Act instead wants to remove the access paths that turn those weaknesses into usable attack routes.

What the Google News Headline Got Wrong

The financing event is real, but the company named in the supplied headline is not the company that raised the money.

The headline identified Corma as a defensive cybersecurity AI startup launching with $60 million. However, the destination was attributed to SiliconANGLE, whose verified July 28 report covers Act Security.

According to the original coverage, Act Security raised $60 million across two rounds. Those rounds consisted of a previously undisclosed $20 million seed investment and a $40 million Series A.

Team8 and Bessemer Venture Partners led the seed round, with participation from Caltech and Hetz Ventures. Notable Capital led the Series A, while Startpoint Capital and SVCI also participated.

Act Security launched publicly alongside the funding disclosure. The company describes its product as an action-centric cloud security platform designed for environments containing human identities, software services, and autonomous AI agents.

Corma is a separate European software company. Its own product documentation says it helps IT teams manage SaaS applications, validate access requests, monitor software use, and recover unused licenses.

The documentation identifies Corma’s founders as Héloïse Rozès, Samuel Bismut, and Nikolai Fomm. It says the company was founded in France in 2023 and raised $4.2 million in late 2025.

Those details conflict directly with the supplied headline. They point to different founders, different funding histories, different products, and different corporate locations.

Corma does operate near the identity and access governance market. Its platform can help organizations discover applications, review access, and reduce unnecessary software exposure. That overlap makes the erroneous headline sound more credible than a completely random company substitution would.

Still, adjacent markets do not make the companies interchangeable. Corma manages software access and usage across an organization. Act Security says it analyzes and restricts the infrastructure pathways that identities and agents can use inside cloud environments.

No verified Corma announcement supports the claim that it raised $60 million or launched the platform described by SiliconANGLE. Corma’s public materials instead continue to present it as a Paris-based access and license governance company.

The most defensible reading is therefore a metadata, aggregation, or upstream labeling error. The available evidence does not establish exactly where that error entered the distribution chain.

This distinction matters because aggregation labels often become inputs for newsletters, monitoring dashboards, and automated article pipelines. Once the wrong entity reaches those systems, later summaries can repeat it without checking the destination article.

A search result is therefore a discovery lead, not final evidence. The publisher page, company announcement, and identifiable corporate records must agree before a funding claim becomes publishable fact.

Why Act Security Raised $60M Now

Act Security is betting that autonomous agents turn old cloud permissions from administrative clutter into immediately exploitable infrastructure.

Act emerged from stealth on July 28, 2026, about one year after its founding. Its funding announcement identifies the company as an action-centric cloud security provider.

The founding team previously built Medigate, a medical-device security company acquired by Claroty. That history gives Act’s investors a concrete operating record, but it does not independently validate the new platform’s performance.

Act’s timing centers on the rapid deployment of AI agents. An AI agent is software that can plan and execute multistep actions through connected applications, cloud services, and programming interfaces.

Unlike a conventional assistant, an agent does not only produce text for a person to review. It can call tools, retrieve data, modify files, create infrastructure, or trigger workflows using whatever authorization it receives.

That ability creates value, but it also changes the consequences of excessive access. A human employee might hold an unused permission for months without touching it. An autonomous process can discover and exercise the same permission during a single workflow.

Act Chief Executive Jonathan Langer told SiliconANGLE that AI agents inherit old human permissions while operating continuously and at machine speed. The company argues that this combination compresses the time between exposure and exploitation.

The startup says approximately 97% of cloud permissions are dormant. That figure is a company claim, not a finding independently confirmed by the reporting cited here.

Even without accepting that exact percentage, the underlying access problem is familiar. Organizations regularly accumulate permissions as employees change roles, contractors complete assignments, services are reconfigured, and applications gain new integrations.

Cloud platforms also contain nonhuman identities. These include service accounts, workload identities, automation tokens, deployment systems, and application programming interface credentials.

Such identities can hold broad privileges because teams prioritize reliable operations during deployment. Removing access later requires confidence that production services will not fail.

AI agents add another identity class to that crowded environment. They may use human credentials, dedicated service accounts, delegated authorization, or connections supplied by an agent platform.

Each pattern creates a different audit trail and failure mode. Yet all of them depend on an organization knowing which actions the agent needs and which actions it should never perform.

This is why Act’s financing is more than another defensive AI announcement. The company is targeting the authorization layer that determines whether an automated action succeeds after a credential or vulnerability becomes available.

Its thesis also fits established security guidance. The NIST zero-trust framework rejects implicit trust based only on network location and emphasizes resource-focused access decisions.

Least privilege is central to that approach. It means giving each person, application, or process only the authorization required for its assigned task.

Act is packaging that principle around a specific 2026 concern: agents can act faster and more broadly than the employees whose permissions they inherit. Investors are funding the possibility that enterprises will need new controls before they expand agent deployments.

The timing also reflects dissatisfaction with security alert volume. Cloud security products can identify exposed services, dangerous configurations, vulnerable software, and excessive privileges. Security teams must still decide what deserves immediate action.

Act claims its platform can reduce that decision burden by addressing reachable paths rather than listing every isolated weakness. The practical value will depend on whether it can remove those paths without blocking legitimate work.

Google News Reveals a Verification Problem for Automated Publishing

The headline error demonstrates how an aggregation layer can preserve the appearance of authority while separating a claim from its actual subject.

Google News helps readers discover reporting from many publishers, but its appearance in a source chain does not independently confirm every headline field. It organizes and routes material that ultimately depends on publisher pages and machine-readable metadata.

That distinction becomes easy to miss in an RSS workflow. A feed item often contains a headline, publisher label, date, and encoded destination URL. An automated system can treat those fields as a complete event record.

Here, that would produce a convincing but incorrect record. The amount, industry, launch framing, and publisher are all attached to a real article. Only the company identity is wrong, yet that is the fact around which the entire story would be organized.

The error could survive several processing stages. A topic generator might create a Corma slug. A keyword system might select Corma-related phrases. A writer could then blend authentic Act funding details with Corma’s genuine access-management product.

That result would contain many true sentences while communicating a false event. This is a more difficult failure than an obviously fabricated company or an impossible financing amount.

Entity resolution is the safeguard. Entity resolution is the process of determining whether names and records from different sources refer to the same real-world organization.

A reliable check compares the company name, official domain, founders, headquarters, product category, funding stage, investors, and announcement date. One matching attribute is not enough.

The supplied event fails that comparison immediately. Corma’s official domain describes a French company founded by Rozès, Bismut, and Fomm. Act’s announcement describes a separate security company founded by the former Medigate team.

Their product language also diverges. Corma emphasizes SaaS management, identity governance, access reviews, software discovery, and license efficiency. Act emphasizes cloud infrastructure, access paths, deterministic boundaries, and agent permissions.

A human editor following the link would probably notice the substitution. A system that summarizes only the feed title might not.

This creates a direct lesson for teams using AI to monitor technology news. Retrieval speed has little value when the pipeline does not preserve a chain from each claim to its supporting source.

A searchable technical knowledge base can help teams retain source documents and compare claims. However, storage alone cannot replace entity checks at ingestion.

The system should treat funding claims as structured records. Company, amount, round, lead investors, announcement date, and source URL should remain separate fields.

Those fields can then be checked against the destination page and an official announcement. If the company name differs, the item should enter a review queue instead of proceeding automatically.

The same rule applies when headlines change after publication. Aggregators can retain an earlier title while the destination article shows an updated one. Editors need both the collected title and the current publisher title to understand the discrepancy.

This is particularly important for Google News results because the platform’s presence can look like secondary confirmation. In reality, several displayed stories can still trace back to one announcement or one mistaken metadata record.

Claim-level deduplication also matters. Three pages repeating the same press release do not provide three independent confirmations.

For this event, the publisher report and Act’s announcement agree on the company, financing total, launch date, and product positioning. Corma’s own materials contradict the company attribution in the supplied headline.

That evidence is enough to correct the event identity. It is not enough to determine whether Google, a publisher feed, or another upstream component originally generated the wrong title.

Act’s Real Opponent Is Alert-First Cloud Security

Act is not primarily positioning itself against Corma; it is challenging security systems that expose risk but leave remediation to overloaded teams.

Traditional cloud security tools often begin with visibility. They inventory assets, scan configurations, identify vulnerable components, map identities, and rank findings.

Those capabilities remain necessary. A security team cannot protect resources it cannot identify, and automated remediation becomes dangerous when the underlying map is incomplete.

The problem arrives after detection. A large organization can receive thousands of findings across development, identity, infrastructure, and compliance systems.

Each finding requires context. Teams need to know whether an asset is exposed, whether an attacker can reach it, whether the permission is used, and whether changing it will disrupt production.

Act says it starts with the action pathways connecting identities, networks, and resources. It then seeks to remove the conditions that allow an attacker or agent to move through the environment.

Consider a contractor who once received database access for a repair. The account may remain active after the assignment ends because nobody wants to risk breaking a later workflow.

An alert-first product can flag that permission. An action-centric product must determine whether it can safely revoke or constrain the access, then keep the restriction from drifting.

The second task is harder because production environments change constantly. Infrastructure code is updated, services are redeployed, teams add integrations, and emergency permissions become permanent.

Act says its platform continuously validates access boundaries. It also integrates with continuous integration and deployment pipelines, which move code changes from development toward production.

That integration lets a security policy intervene before a configuration reaches a live environment. The company claims it can block changes that violate established access boundaries.

This approach resembles infrastructure policy enforcement, identity governance, network segmentation, and cloud posture management. Act’s differentiation depends on combining those functions around reachable actions rather than presenting separate findings.

The startup says it evaluates identity, network, and AI access together. That matters because an apparently narrow permission can become dangerous when a reachable service provides another credential or network path.

An attacker who compromises one component often tries to move laterally. Lateral movement means using an initial foothold to reach additional systems inside the environment.

Act wants to restrict those routes before an intrusion occurs. If an attacker compromises one workload, tightly bounded permissions should reduce what that workload can access next.

AI agents make the model more urgent because they can produce accidental lateral movement without malicious intent. An agent might select the wrong resource, interpret an instruction too broadly, or invoke an integration under excessive authorization.

The platform’s central promise is prevention through structural limits. Yet alert-first and action-centric security are not mutually exclusive.

Act still needs visibility to understand identities, dependencies, and intended behavior. A remediation engine built on an incomplete model can remove necessary access or leave a hidden route untouched.

Established vendors can also add permission analysis and automated remediation to existing platforms. They may already possess customer relationships, deployment data, and integrations that a new vendor must build.

Act’s funding gives it time to prove that a dedicated architecture produces better outcomes. It does not guarantee that action-centric security will become a separate product category.

The company also faces a measurement problem. Alerts are easy to count, while prevented incidents are inherently difficult to observe.

Useful customer evidence would include reductions in standing privilege, fewer reachable attack paths, shorter remediation times, and low rates of business disruption. Public case studies have not yet established those outcomes at broad scale.

What the $60M Announcement Does Not Prove

The launch validates investor interest, but it does not validate Act’s coverage, accuracy, or safety inside complex production environments.

The platform’s claims currently come mainly from Act and its investors. Those parties understand the product, but they also benefit from presenting its market opportunity in favorable terms.

Liran Grinberg, managing partner at Team8, described Act as a platform that removes cloud risk instead of merely identifying it. That statement clarifies the investment thesis, not an independent comparative test.

Act’s founders also argue that agents can exploit exposure in minutes rather than months. Machine-speed automation makes rapid action credible, but exploitation time depends on the environment, model, tools, permissions, and attacker.

The company must therefore prove several layers of performance. First, it needs broad discovery across cloud accounts, identities, networks, services, deployment pipelines, and AI systems.

A missed identity can undermine the access map. An unknown service account or unmanaged integration may preserve a route that the platform considers closed.

Second, Act must infer legitimate access accurately. Usage history can show which permissions were exercised, but unused does not always mean unnecessary.

A disaster-recovery permission might remain dormant until an emergency. A quarterly finance process can appear inactive during most observation windows.

Third, the company must constrain access without causing outages. Cloud authorization policies are interdependent, and an apparently safe change can interrupt a background service.

Deterministic boundaries can limit that risk if administrators define them correctly. They cannot eliminate errors in policy design, environment discovery, or dependency mapping.

Fourth, Act needs meaningful controls for agent identity. An organization cannot govern an agent consistently if the agent alternates between employee credentials, shared tokens, and service accounts.

Security buyers should ask whether the platform identifies each agent separately, records delegated authority, and connects every action to an accountable owner. They should also examine how emergency overrides work.

Fifth, the company needs protection against its own concentration of access. A security platform capable of mapping or modifying cloud permissions becomes a sensitive component.

Customers will need evidence covering isolation, audit logs, administrative controls, data handling, incident response, and the security of Act’s deployment model.

The funding announcement does not supply independent answers to those questions. It also does not disclose customer counts, measured attack-path reduction, false-positive rates, or production outage rates.

That absence is normal for a company leaving stealth. It still limits the conclusions buyers and journalists should draw from the launch.

The broader least-privilege concept is well established. NIST’s implementation guidance includes identity governance, microsegmentation, and access management among the components of zero-trust deployments.

Act does not need to prove that excessive privilege is dangerous. It needs to prove that its method can reduce privilege faster and more safely than existing tools and internal engineering processes.

Corma faces a related but narrower verification challenge in its own market. Access reviews and software discovery can identify unnecessary SaaS accounts, but organizations still need reliable connectors and accurate ownership records.

The two companies therefore touch the same governance principle from different layers. That conceptual overlap probably contributed to the plausibility of the incorrect headline.

It does not support merging their claims. Funding, product performance, and customer results must remain attached to the company that actually reported them.

What to Watch After the Corma Google News Mix-Up

Three signals will show whether this episode becomes an aggregation footnote or the start of a credible new cloud security category.

The first signal is independent evidence from Act Security customers. Named deployments should report measurable reductions in standing permissions, reachable attack paths, and remediation time.

The strongest evidence would also disclose operational cost. A platform that removes risky access but triggers frequent outages would exchange a security problem for a reliability problem.

Independent customer results would strengthen Act’s claim that action-centric controls improve on alert-first workflows. Continued reliance on executive statements would leave that claim largely untested.

The second signal is integration depth. Act says it evaluates identities, networks, and AI access while enforcing controls through deployment pipelines.

Buyers should watch which cloud platforms, identity systems, agent frameworks, and development tools receive production-grade support. Coverage across a demonstration environment is different from coverage across a multinational company.

Agent-specific controls deserve close attention. Separate identities, narrowly delegated tools, action logs, approval gates, and revocable credentials would show that the product addresses agents directly.

If Act mainly governs conventional service accounts, its product can still be useful. However, its AI-era differentiation would become less distinct.

The third signal is the response from established cloud security and identity vendors. They already collect much of the data needed to map permissions and reachable assets.

If those vendors add reliable action-path reduction, Act will face pressure to prove a technical or operational advantage. Partnerships or acquisitions would indicate that the market sees action-centric enforcement as strategically important.

Editors and automated publishing teams should watch a separate signal: whether the faulty Corma headline continues appearing in derivative stories. Repetition would show how slowly corrected facts move through syndicated systems.

The immediate editorial action is straightforward. Correct the company to Act Security, preserve the original headline as provenance, and record the mismatch for future deduplication.

Readers following Google News should apply the same discipline to high-value claims. Open the destination, verify the corporate identity, and check whether an official announcement supports the central facts.

For security buyers, the larger question is whether access controls can keep pace with autonomous software. Track Act’s customer evidence, agent integrations, and remediation safety before accepting its category claims.

For knowledge workers, the lesson is equally practical. Save the source behind a headline, not only the headline itself, and keep claims connected to their evidence.

The real story is not that Corma received $60 million. It did not, based on the available evidence. The real story is that Act Security raised the money to test whether cloud defense should remove dangerous actions before another alert reaches the queue.