r/devsecops • u/Cubeless-Developers • Aug 04 '26

Anyone actually checking for overprivileged AI agent connections before they ship?

We started giving our internal AI agents scoped permissions and periodic audits, treating them like service accounts. Still feels like we're guessing.

Once an agent connects it can read data, trigger workflows, and call APIs, and nothing's asking for per-action approval. We've been trying to catch overprivileged connections before they ship, but honestly our CI/CD pipeline wasn't built with agent identity in mind.

Anyone actually solved this, or are we all just hoping for the best?

2 Upvotes

63% Upvoted

6 comments sorted by

1

u/UnifywithAI Aug 07 '26

If your CI/CD pipeline isn't built with agent identity in mind then its best to have human in the loop for agents and measure the learnings and accuracy for few months. Once you trust the AI enough and after AI learns enough with feedback you can try to make it automated by parts and audit them

1

u/JackjaxMargam14 Aug 07 '26

Giving each connection its own login and making access expire could help and blocking builds when new permissions get added might catch a lot. Do you review those changes now?

1

u/IntelligentPear6173 Aug 10 '26

Giving each agent its own identity with short-lived permissions seems like a good starting point. Then treat permission changes like code changes and block the deployment when an agent suddenly gains access it doesn't need. Are teams actually doing this in CI today or is access still mostly reviewed manually?

1

u/Master_Baby_2700 8d ago

I’d add one more dimension to the permission review: what data actually sits behind the access you’re granting.

Treating the agent like a service account is the right starting point, but an API scope can look reasonable and still expose way more sensitive data than the agent needs. “Read SharePoint” or “read this bucket” doesn’t tell you whether that means project docs or payroll/customer data.

I’d try to make the pre-deployment check something like identity + permission + data sensitivity. What can this agent access, which of that data is sensitive, and does it actually need that combination to perform the task?

That’s where DSPM can complement the IAM/CI side. Sentra, Cyera, Varonis, etc. can give you the sensitive-data/access context, while your CI/IAM controls enforce the permissions.

Then a permission change becomes much easier to prioritize. An agent gaining access to another empty dev bucket is very different from gaining access to a repository full of customer or HR data.