If soc audits are driving your development process you are doing it backwards. And _certainly_ a time is coming when just using the llm will be soc compliant.
I’d think any company big enough or working in certain markets which has a Compliance Officer cares about this; regulations are a legitimate business risk, and software integration contracts have security control compliance requirements which very much impact the sdlc.
Would you have the same reaction to requiring an approval for a production deployment? That’s driving the development process.
—-
Also jfc I need to cool it with the buzzwords, sorry I just got home from “talk like this all day” $job
A joke or not, a lot of organizations take SOC compliance and auditing seriously. Responding to someone requiring it with “who cares, the accountants doing the audits don't know anything anyway” is unlikely to go well.
I'm intimately familiar with SOC2 and I'm telling you it has practically nothing to do with software security and to the extent it does, the story is improved starkly and mechanically by agents. That's an outcome of how superficial SOC2 is, not a statement about how good agent code is.
Of course, the reality is that competent orgs generally exclude virtually all their software from their audit scope, and it would be a mark of incompetence to loop tooling-grade or line-of-business backoffice code into it. But even if you were crazy enough to do that, agents would improve your outcome.
Anybody claiming that SOC2 is a reason agent-based code will falter is talking about the world as they want it to be, not as it is.
Your word for “competent” seems to be my word for “irresponsible”. A failure in that “line-of-business backoffice code” is exactly the sort of thing that'd cause irreparable damage in terms of regulatory compliance (and, you know, the tangible harms those regulations are meant to prevent). An LLM hallucination introducing bugs that make ERP transactions spontaneously disappear or allow users to bypass permissions checks on sensitive documents is the sort of thing that's catastrophic for any business that's not actually just a money laundering front (and hell, even then). Maybe you trust agentic AI to make fewer mistakes than humans, but I sure don't.
Like, I'm trying to avoid hyperbole here, but you're advocating for a wild-west sort of attitude that can, will, and has gotten people severely defrauded or outright injured/killed. And I know you know better than this because you've written at length about what it took to achieve SOC compliance at your current employer.
If soc audits are driving your development process you are doing it backwards. And _certainly_ a time is coming when just using the llm will be soc compliant.
I’d think any company big enough or working in certain markets which has a Compliance Officer cares about this; regulations are a legitimate business risk, and software integration contracts have security control compliance requirements which very much impact the sdlc.
Would you have the same reaction to requiring an approval for a production deployment? That’s driving the development process.
—-
Also jfc I need to cool it with the buzzwords, sorry I just got home from “talk like this all day” $job
SOC2 is generally regarded as a joke and has in fact almost nothing to do with software resilience even on its own terms.
A joke or not, a lot of organizations take SOC compliance and auditing seriously. Responding to someone requiring it with “who cares, the accountants doing the audits don't know anything anyway” is unlikely to go well.
I'm intimately familiar with SOC2 and I'm telling you it has practically nothing to do with software security and to the extent it does, the story is improved starkly and mechanically by agents. That's an outcome of how superficial SOC2 is, not a statement about how good agent code is.
Of course, the reality is that competent orgs generally exclude virtually all their software from their audit scope, and it would be a mark of incompetence to loop tooling-grade or line-of-business backoffice code into it. But even if you were crazy enough to do that, agents would improve your outcome.
Anybody claiming that SOC2 is a reason agent-based code will falter is talking about the world as they want it to be, not as it is.
Your word for “competent” seems to be my word for “irresponsible”. A failure in that “line-of-business backoffice code” is exactly the sort of thing that'd cause irreparable damage in terms of regulatory compliance (and, you know, the tangible harms those regulations are meant to prevent). An LLM hallucination introducing bugs that make ERP transactions spontaneously disappear or allow users to bypass permissions checks on sensitive documents is the sort of thing that's catastrophic for any business that's not actually just a money laundering front (and hell, even then). Maybe you trust agentic AI to make fewer mistakes than humans, but I sure don't.
Like, I'm trying to avoid hyperbole here, but you're advocating for a wild-west sort of attitude that can, will, and has gotten people severely defrauded or outright injured/killed. And I know you know better than this because you've written at length about what it took to achieve SOC compliance at your current employer.
I believe that if you read what I wrote about that you'll see it's consistent with what I'm saying here.