LATEST / 24.09.26
● MIGGO NAMED A 2026 SINET16 HONOREE● GRAFANA CLOUD COLLABORATION BUILDS ON PRODUCTION TELEMETRY
People / Software & the people who build it

Daniel Shechter and the trouble with a perfectly good lock

Before co-founding Miggo Security, Daniel Shechter played jazz saxophone, worked in military intelligence and took a detour through McKinsey. His next question was deceptively simple: what happens after software lets someone in?

Advertisement

Daniel Shechter played jazz saxophone in high school. It is an agreeable detail to encounter in a career otherwise populated by intelligence units, consulting engagements and the less melodious phrase “application detection and response.” Before there was a company to explain, there was an instrument to learn. Jazz remains among his interests, alongside sports. The corporate biography has room for something you might actually discuss over dinner.

Born and raised in Tel Aviv, Shechter would go on to serve in Israeli military intelligence, work at McKinsey & Company and co-found Miggo Security. He is now based in New York. The route between those points includes a useful interruption: he became an officer before deciding to start again as a cyber researcher. His career contains more deliberate apprenticeship than the familiar founder biography, with its suspiciously straight line from childhood curiosity to company formation.

Today, his business concerns the behavior of software while it runs. Applications contain services that exchange information, accept credentials and grant one another permission. Each interaction carries an assumption about what happened earlier. Shechter and his co-founder, Itai Goldman, built Miggo around those relationships. A perfectly serviceable lock offers limited comfort when the next room has agreed to trust whoever walks through it.

The musical beginning offers a pleasing image, but Shechter’s own account of learning cybersecurity supplies the more revealing detail. He remembers sitting with his wife, who also works in computer security, to understand the basics. A future security CEO needing an explanation at home is a more useful career lesson than another story about effortless talent. Expertise had to be assembled. The title came later.

An officer starts again

Shechter is a graduate of the Havatzalot intelligence training program. His early service involved intelligence work before he moved into Unit 8200’s cyber sector. He was attracted by the practical impact of the work: the possibility that a small group could turn an idea into a result quickly. Already an officer, he entered the technical field as a researcher and progressed into team leadership.

One recollection gives that attraction a human scale. A soldier on his team suggested an idea; two people went from an apparent dead end to a working result in less than a day. He has described the experience with evident excitement. The anecdote concerns a team member’s initiative as much as his own leadership. The person with the idea gets a place in the story.

After leaving the military, he chose consulting. At McKinsey, he worked as a consultant and engagement manager, helping enterprises and technology businesses with strategy. He has explained that he wanted to learn the business side of cybersecurity. It was a purposeful change of classroom, from technical operations to the decisions that determine what companies build and buy.

His studies also extend beyond computing. He holds a master’s degree in Middle Eastern studies and a bachelor’s degree covering economics and Middle East history. Alongside the technical service and commercial work, those subjects make for an unusually varied reading list. They do not explain every later decision, but they establish that the founder’s preparation crossed several disciplines.

The consulting interlude matters because a security product eventually has to survive a conversation about budgets, staff and responsibility. Finding a weakness and persuading an organization to change its habits require different abilities. Shechter sought experience on both sides of that exchange. By the time he returned to building with Goldman, he had spent time learning how technical problems become management decisions.

Miggo co-founders Itai Goldman, left, and Daniel Shechter, right, wearing company T-shirts
Two founders, one inside job. Itai Goldman (left) and Daniel Shechter. Photo: Miggo Security.

A company named for the inside

Shechter met Goldman early in his career, while they served together in Unit 8200’s cyber sector. Goldman became Miggo’s co-founder and chief technology officer; Shechter became CEO. Their partnership joined an existing professional relationship to a shared concern about how software was changing. Increasingly, an application’s behavior depended on several services working together, often across organizational boundaries.

Miggo emerged from stealth in April 2024. Its name comes from an Aramaic word meaning “from the inside,” an unusually economical explanation of a security company’s premise. The team wanted to inspect relationships within a running application: where requests travelled, how authentication worked and which components trusted which other components. The name does a fair portion of the introductory sales meeting.

Shechter’s argument begins with an ordinary organizational difficulty. A company can have people responsible for code, cloud infrastructure and incoming traffic without any one of them seeing the complete journey of a request. In his public explanations, he asks what an application does, how it normally behaves and where its architecture leaves room for misuse. The questions arrive before the product vocabulary.

Consider a simplified example: a service receives a request and passes it to another service that assumes identity checks have already happened. Both components may be doing their assigned work. Their agreement about responsibility can still leave a dangerous gap. The weakness belongs to the relationship between them. This is an illustration of the problem Miggo addresses, rather than an account of a particular customer incident.

Application detection and response, usually shortened to ADR, turns that concern into a product category. Shechter’s writing emphasizes live interactions and the context around suspicious behavior. His case for the technology also leaves a place for earlier checks during software development. The running system adds another place to look, especially when the assembled application behaves differently from the picture its individual parts suggest.

AN APPLICATION, IN RELATIONSHIPS
01RequestSomeone asks to enter
02IdentityCredentials are checked
03Service → serviceTrust travels with the request
A simplified illustration of the relationships that runtime security examines. Each handoff carries an assumption.

When trust became the test case

In August 2024, Miggo publicly disclosed research it called ALBeast. The issue concerned configurations of applications using AWS Application Load Balancer authentication. It offered a concrete example of the trust problem Shechter had been describing: an application needed to establish that an authentication token came from the expected load balancer, rather than merely accept a token that appeared properly signed.

The distinction matters. AWS said the technique depended on a misconfigured customer application, rather than a flaw in the AWS service itself. Miggo’s advisory acknowledges that position and describes the issue as configuration-based. The research team reported it to AWS in April 2024; subsequent documentation changes addressed signer validation and restrictions on traffic reaching application targets.

For a young company, research like this gives a technical argument a test case. It also makes the limits of that argument visible. The discovery belonged to Miggo’s researchers, and the underlying problem crossed the boundary between a cloud service and its customer’s implementation. Shechter’s role was to connect such findings to the company’s wider purpose without collapsing every responsibility into a single convenient villain.

There is a particularly modern discomfort in this kind of failure. Each participant can describe its own job accurately while the combined system remains exposed. “Shared responsibility” sounds reassuring until someone has to determine exactly where the sharing stops. Shechter’s business operates in that awkward space, where architecture diagrams become a set of assumptions someone must actually check.

“We’re here to block the attack while you fix the issue.”

Daniel Shechter · April 2025

The interval a patch cannot erase

In April 2025, Miggo announced a $17 million Series A led by SYN Ventures, with continued participation from YL Ventures. Together with its earlier $7.5 million seed financing, that brought reported funding to $24.5 million. The money gave Shechter and Goldman resources to develop the product and expand the business. Funding is a milestone in building a company; customers still have to make the technology part of their working day.

Shechter frames the objective around protecting an application during the work of repairing it. That puts a familiar enterprise constraint into plain language. A team may understand a vulnerability and still need time to test a change, arrange deployment and avoid interrupting a service. Knowing the answer does not immediately make the repair appear in production.

The interval between discovery and repair has become central to his public argument. Miggo’s approach seeks to establish which weaknesses can actually be exploited in a particular application and apply a protective measure while a permanent fix is prepared. For Shechter, this turns security into a question about sequence: what action can protect the running business now, and what engineering work follows?

His broader aspiration is to let organizations keep developing software safely. “We’re here to facilitate innovation securely,” he has said. The ambition includes an operational courtesy: developers need to ship changes, and security teams need a way to act without making every unresolved issue a company-wide emergency. A product must fit into those working relationships as well as into the application.

TWO DISCLOSED ROUNDS · COMPANY FUNDING
2024 · Seed
$7.5M
2025 · Series A
$17M
$24.5 million in reported financing across the two rounds. Bar lengths show round size; these figures represent capital raised.

The information may already be there

By March 2026, that interest in working relationships had a tangible expression. Shechter co-authored a Grafana Labs article with Jonathan Price about a partnership between Grafana Cloud and Miggo. The proposed workflow builds security analysis on production telemetry that engineering teams already collect, including traces and profiles. It carries his interest in the application’s interior into an existing engineering practice.

The appeal is easy to understand. A trace helps reveal the journey of a request; a profile helps show what code ran. Using those signals for security gives engineers and defenders something concrete to discuss together. The collaboration also addresses the inconvenience of asking teams to deploy yet another sensor. A tool that needs cooperation has to take the cost of that cooperation seriously.

In September 2026, Miggo announced its selection as a SINET16 honoree. Shechter used the occasion to return to protection during the patching interval. The company’s recognition and its partnerships are separate milestones, but the emphasis in his public language remains consistent: understand the running application, establish the relevant risk and create room for teams to carry out the repair.

The person behind that argument is still recognizable in the earlier career. He made a technical transition after becoming an officer, deliberately sought commercial experience and returned to build with someone he already knew. His public accounts give colleagues, his co-founder and his wife roles in what he learned. That is a more populated origin story than the solitary-founder version.

There is no need to recruit the saxophone as a secret explanation for any of this. It belongs in the portrait because he played it, and because a person should be allowed an interest that does not have to justify a business model. The thread that does carry through his working life is the willingness to investigate the machinery underneath a result. For Shechter, the next useful question is usually somewhere inside.