The group publishes the following entry rules on the event listing:

• Meetup QR-code check-in, in use since May 2026, restricts entry to registered users.
• Registrants must give a first and last name that matches a photo ID. Organizers send the name list to building door security before the event.
• Door security checks the name and photo ID at entry. Organizers or building security may refuse entry on a mismatch.
• Entry requires a confirmed RSVP. A wait-list position does not grant entry; it moves a person to the registered list only when a registrant cancels more than 48 hours before the event.
• The group tracks no-shows. Three no-shows remove a member from the group. Repeated cancellations with less than 48 hours' notice can count as no-shows.
• Pets and telepresence robots are not admitted.

At this event, attendees passed two security checkpoints in the building, and staff checked names against the registration list at both.

From the welcome slide:

Transcribed from the slide above, so the dates and locations are what was announced on the night. None has been checked against the events' own published listings except MinuteCon, which has been: it is a two-day conference, 30 April to 1 May 2027, at the Boston Marriott Cambridge, run by NEISA, the same organization that runs this meetup. See MinuteCon 2027.

The organizers announced a "Secure in Shadow" award.

Few attendees or sponsors announced open positions. DomainTools announced openings for a software engineer and a product manager.

• Product area: security data pipeline covering data in transit, ingest, and redaction. The sponsor slide's own line is "the SOC-aware security data pipeline."
• Market position: competes with Splunk on ingest and redaction.

Recovered on 2026-09-17 from a photograph of the sponsor title slide; the name was not written down on the night.

• Speaker: company executive.
• Product area: domain intelligence, including detection of newly registered and reactive domains.
• Hiring: software engineer, product manager.

End users and developers deploy AI agents faster than security teams adopt controls for them. Agents have leaked sensitive data, executed destructive actions, and caused financial losses. Garbis applies the Zero Trust principles used for users and workloads to agents through three mechanisms: agent identity, authorization, and action control. The talk introduces an agentic AI maturity model and a reference architecture built on open-source identity and policy components. The reference architecture uses the Ory project components (Kratos, Hydra, Talos, Keto, Oathkeeper).

Garbis cites NIST SP 800-207, which defines Zero Trust as "a set of guiding principles for workflow, system design and operations." The slide states that Zero Trust is neither an architecture nor a product, and lists four core principles:

1. All communication is secured regardless of network location.
2. Access to resources is determined by dynamic policy.
3. All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
4. The enterprise monitors and measures the integrity and security posture of all owned and associated assets.

The four principles correspond to tenets 2, 4, 6, and 5 of the seven tenets in NIST SP 800-207 section 2.1.

• AI agents differ in how they are built, deployed, and operated, in how they are used and abused, and in how an enterprise secures them.
• Security practitioners need a taxonomy that assigns controls, technologies, and processes to each agent type.

• An audience poll on security-team readiness for agentic AI returned scores at or below zero (responses included -3 and 0).
• Garbis described consumer and desktop agent products (Claude chat, Claude Cowork) as expanding the set of systems and data a single user session can reach.
• Agent workloads can move between cloud, desktop, and mobile runtimes.
• Garbis maps threats using OWASP and MITRE taxonomies.
• The two primary risk classes are prompt injection and excess access.
• The talk's goal is a method for defining enterprise controls per agent.

Garbis poses the same set of questions for every agent deployment:

Agents run on three locations: mobile, desktop, and cloud. Garbis classifies agent deployments into five forms:

1. Chat interfaces.
2. Harnesses (for example, Claude Code).
3. Multi-agent swarms calling cloud model APIs.
4. Sandboxed agents.
5. Agents embedded in workspace tools (Slack, Microsoft Teams).

Each usage category determines whether the agent has its own account, what access it holds, and how its provenance is established.

Solid edges show the classification stated in the talk. Dashed and dotted edges show typical mappings inferred from the examples given; the talk did not present a complete mapping.

• Garbis stated that Claude Cowork activity does not appear in the Anthropic Compliance API. Security teams therefore need to track two things: agent events, and application changes that alter what telemetry exists at all.
• For Claude Code, the combination of dispatch, a sandbox, hard egress restrictions, and filesystem controls may not meet enterprise requirements on its own.
• A complementary control layer is an egress proxy that rewrites requests to inject credentials and emits telemetry for each call.
• An open question from the talk: how much line-of-business staff and security teams each know about the agents running in their environment.

The talk covers how human-operated ransomware campaigns proceed from initial access to encryption. Davis walks through a real intrusion and converts it into a defender playbook with three parts: controls that stop each stage, detections with the highest value, and backup and recovery practices that let an organization recover without paying. Attendees receive a prioritized checklist.

This talk does not overlap the current research areas listed below. The entry records the abstract and structure only.