u/Left-Exam8697

We use CrowdStrike primarily for endpoint and EDR, and recently tried leaning on their cloud security module's AI-SPM capabilities for Azure visibility. tbh It felt like an extension of the endpoint product rather than something cloud-native, and it missed a couple of shadow Azure OpenAI deployments we later found manually. not sure if others have had better luck or if this is a known limitation of endpoint-first platforms extending into cloud AI visibility.

Different problem class from employees pasting things into a chatbot, and I do not think most controls have caught up.

We now have agents with tool access. They can call internal APIs, query databases, hit external services, and chain those actions without a human approving each step. From the network's perspective it is a service identity making a lot of legitimate-looking outbound calls. From a governance perspective it is a non-human actor with standing permissions and no meaningful audit story.

Specific gaps I cannot close with existing tooling include intent, because I can see the call but cannot see why the agent decided to make it; blast radius, because an agent with read access to three systems can join data in ways no single human role was scoped for; revocation, because killing a compromised or misbehaving agent mid-run is not clean; and attribution, because when the agent acts on behalf of a user, it is unclear whose policy applies.

Most "AI security" platforms I have looked at are still oriented around prompt/response inspection for human chat use. A few are starting to talk about agent identity and runtime policy.

What is actually working for people here: agent-specific runtime controls, or are you handling it upstream with tighter scoping and short-lived credentials?

The whole appeal of Replit, Lovable and Bolt is skipping the SDLC entirely, prompt to live URL in minutes, with no pull request for security to hook a check into, and honestly that's the pitch working exactly as intended, it's just not intended for us. The core problem isn't the app we know is being built on one of these platforms, because at least there you can have a conversation about it, it's the one nobody mentions, built by someone in another department who never looped security in and has no reason to think they should have, since as far as they're concerned they just made a form or a dashboard, not "shipped infrastructure."

We've tried a few things on our end, adding it to onboarding, sending reminders in engineering channels, none of it really moves the needle because the people building these apps aren't reading security's Slack channels in the first place. How is everyone else gating something that structurally bypasses the pipeline, especially when the org chart means the builder and the reviewer will never naturally cross paths?

The whole appeal of Replit, Lovable and Bolt is skipping the SDLC entirely, prompt to live URL in minutes, with no pull request for security to hook a check into, and honestly that's the pitch working exactly as intended, it's just not intended for us. The core problem isn't the app we know is being built on one of these platforms, because at least there you can have a conversation about it, it's the one nobody mentions, built by someone in another department who never looped security in and has no reason to think they should have, since as far as they're concerned they just made a form or a dashboard, not "shipped infrastructure."

We've tried a few things on our end, adding it to onboarding, sending reminders in engineering channels, none of it really moves the needle because the people building these apps aren't reading security's Slack channels in the first place. How is everyone else gating something that structurally bypasses the pipeline, especially when the org chart means the builder and the reviewer will never naturally cross paths?

been doing a stack review for our org and the IAM market feels more crowded than ever, but half of it is repackaged provisioning with a new logo. we're on entra for the core directory, but a big chunk of our estate is legacy apps, homegrown stuff, service accounts nobody remembers creating, and a growing number of agents/bots that technically have credentials nobody's tracking. governance tools keep telling us we're compliant, but that's based on what's plugged in, not what exists.

what's in your stack right now that you'd recommend keeping, and what did you rip out?

I did a security assessment for a logistics company last year about 110 sites, fully migrated to a cloud-native SD-WAN platform.. proud of the deployment. When I asked them to walk me through the access controls on their SD-WAN orchestrator...the answer was essentially "it's behind MFA." That was it. wow. i mean No privileged access workstation requirement, no just-in-time access mode... no alerting on configuration changes, and like the orchestrator credentials were shared among four engineers on the network team. The orchestrator for a 110-site WAN fabric is an extraordinarily high-value target, and they'd treated it like a regular admin console.

now Beyond the orchestration plane, the data plane security story had some real gaps too. Certificate rotation for the tunnel encryption had never been done since the initial deployment two years prior..so like he cipher suite configuration was at vendor defaults that included options I'd have removed, and there was no monitoring for anomalous tunnel behavior things like tunnels establishing to unexpected peer IPs or unusual path selection changes that could indicate traffic redirection. None of these were exotic attack vectors..they were operational hygiene items that fell through because the team's attention had stayed on the WAN performance and availability story rather than the security posture of the SD-WAN infrastructure itself. We wrote up the findings and the company addressed them over the following quarter. Does anyone have a reasonable checklist they've used for SD-WAN security posture reviews, or has everyone been building these from scratch?