Cameron Gaudet: Well, hello all and welcome back to the Aware AI Brief. at this point you probably know what this this podcast series is about. For those of you that might not, this is where we get together, Walter and myself and kind of go through different questions that you, the the listener, the reader, the engager, if that were a word, we'll we'll we'll coin it here. You've heard TM, TM here. But for those of you that have questions, just a continued discussion about specifically practical use or practical experience and just day-to-day encounterings with with AI governance-related topics, discussions, questions, and what have you. So that's that's the the gist of it. If if you're new, welcome. but as always, I am here. my name is Cameron Godet, and I am joined by Walter Haydock of Stack Aware. Walter, how are you doing today?
Walter Haydock: Doing well, Cameron. Good to see you again as always.
Cameron Gaudet: Good to see you. Good to see you as well. And and looking forward to maybe the end of October already, which is kind of crazy to crazy to think about already. but but anyways, flying flying right through. I'm always jealous of yourself. We were talking a little bit right before before coming on here about the the cooler temperatures. And this is this is usually a really fun season for for those of you that might live in in areas where the the leaves change color and the temperatures change. We're just we're warm bathwater temp here in in Oklahoma. Not quite, not quite fall, but yeah. Good time of year. Good time of year. But so without out further ado, wanted to get in. We've got actually quite a few questions here that came through came through from this past month. So wanna jump right into it and and kind of dive into some of these some of these queries, some of these topics and and discussion points. So First and foremost, a question had come through via via LinkedIn. How do you get executives to actually show up for management review? I thought that was a really good practical question there.
Walter Haydock: most important thing that compliance, security, privacy, and legal teams can do to get business leaders to show up to AI governance and management reviews is to discuss things that are relevant to them. So if you're coming up with obscure ways of discussing AI-related risk, but you're not really focusing on the business impacts of them, if you're not closely tracking product releases or business expansions, things like that, you're going to lose the attention of executives very quickly. So it's important to align your AI management system to the business's objectives. And ISO 402001 explicitly requires that you do that. So when you're building your AI objectives, when you're building your measurement and monitoring program, it's key to ensure that you're tracking things that are important to the business. Now they may be risk mitigation items, they could be AI accuracy items, there are ways to tackle both the risk side as well as the business side. And that is how you get executives to attend management reviews. I saw another GRC leader actually, and I can call her out because this is public, Linda Fry from Infoblox. She posted that if GRC leaders are making their own dashboards just to satisfy their own needs. and then they expect the business to for some reason just start paying attention to what they're doing, they're gonna be soberly mistaken. So I always recommend using quantitative risk management and measurement to ensure that you're communicating in ways that the business can understand. Cause if you start talking about things like the CVSS score, common vulnerability scoring system, which I think I don't even think security practitioners should use, but let alone business
Cameron Gaudet: Yeah.
Walter Haydock: leaders, if you expect them to worry about what the C VSS score of an item is, then you're going to be sorely mistaken. So I think the zeitgeist is to align security with business objectives. And that's how you get executives to show up for management review.
Cameron Gaudet: Yeah. Yeah. And and tying it to there there was a part of part of my thought process process when I had seen this question was was just how do you have how do you have engaging conversations with anyone, right? You talk about things that they wanna talk about and you put it in terms where there is there is mutual interest and and mutual understanding for sure. So it's it's it's same as same as walking into a room and wanting to carry on a conversation with somebody, be able to be able to talk in ways that that person is then interested in. So very, very good point. The next next question that had come in said, I'll just read this verbatim. If we take the forming, storming, norming, performing cycle, explicit communication, back up, I think this was in reference to a post you had made about explicit communication, but it belongs to the first stage, the forming, and implicit to the last stage, the performing. But how do you move a team through these stages quickly? So maybe how how in practice do you promote and encourage and grow that explicit communication?
Walter Haydock: So, for highly performing organizations, they will use two different types of communication. Explicit communication is I tell you exactly what to do, I have check-ins, I have follow-ups, you confirm when you're done, and then we have a close-out meeting and we say, okay, we're done with this task. Implicit communication cuts out a lot of those steps and only relies on key milestones or indicators along the way. So if I give you a task. Via Jira ticket, then you do the task and you close the ticket. And then I'm automatically notified that you did the task. that you're done. I know that you're done. We all are speaking the same language. We have the same definition of done. We have the same standard operating procedures. There's no confusion as to what happened. So you need to start with explicit communication. You can't skip that. However, the goal would be to maximize the amount of implicit communication that's going on. During any given activity task that the team is conducting. So to accelerate that, you need to run a lot of cycles. That means you can do training exercises, you can do real, you can do stuff for real, you can work on real projects. The faster that you can run that cycle, the faster that you can go through a series of tasks from beginning to end, the more quickly you're going to be able to go from pure explicit to mostly implicit communication. The explicit never goes away, but the more you can rely on implicit, the more efficient you'll be and the faster you will be able to move.
Cameron Gaudet: Yeah. Yeah, makes makes sense because the less the less you have to spend time talking about it, the quicker quicker you're actually gonna be able to do things and and accomplish objectives there. the yeah, go ahead.
Walter Haydock: And some something to add on that on that. So this is I'm gonna tease something that I'm gonna be putting out soon, but something from the Marine Corps that I think is very useful is the five-paragraph order format, which is basically a structured data format. It you could put it in in a JSON, no problem. And it's a way that you explain anything to your team before you're about to execute it. You say, here's situation, here's the mission, here's the execution, here are the administrative and logistical concerns, and here are the communication and signaling requirements for this operation. It's a structured format and it is standardized across the Marine Corps. And what I'm exploring is something called the Vector Framework, which is gonna closely mirror the Marine Corps SMIAC format. Not a very good acronym, by the way.
Cameron Gaudet: Okay.
Walter Haydock: SMEAC. So the the vector framework will allow for the the correct balance between implicit and explicit communication and it'll be useful when communicating with people, but also with AI agents. It will explain what level of delegation is authorized, you know, who's ultimately accountable for the outcome and how to log and record things along the way. So wanted to tease that. Follow me on LinkedIn if you want to see the
Cameron Gaudet: Hm. Yeah. Yeah.
Walter Haydock: the framework when it comes out.
Cameron Gaudet: Right. Yeah. Stay tuned for that, especially especially the gentleman that had the question, but for for all people that are following along and and look forward to look forward to see that. Love love a love good format, love a good framework, right? things that things that can be easily applied. things that are practical. That's the point of this conversation, to have to practicality. So look for that very practical, practical tip coming to a LinkedIn near you. The next question, how do you see organizations handle, maybe more on the experience side of what you've seen, how do you see organizations handle shadow AI in their risk registers when they don't yet have full visibility of what's being used?
Walter Haydock: Risk registers should always tie risks to specific assets. So this is a great question because with shadow AI, you don't necessarily understand what your assets are. Now you could, you should understand what sorts of data you have access to, whether that's customer information, whether that's protected health information, whether that's intellectual property, trade secrets, things like that, which can't be exposed to unintended training, for example. So Start with the data if you don't have a good idea of the assets in use, because that would allow you to do the type of risk assessment that you need to. you can look at the types of risks that could occur without necessarily understanding exactly which systems are in use. So if you are concerned about third-party generative AI providers training on your sensitive data, you wouldn't necessarily say, you know, Chat GPT is training on my sensitive data, but you could say unintended training on this type of customer information is a risk and you can put that in the register and you can make calculations about what you think the likelihood of that occurring is and what the impact of it occurring is.
Cameron Gaudet: Hm. Yeah, it's that's good. Really again, really practical, practical help, practical advice for that. and something that all organizations are going to have to handle, right? That's are going to have to deal with either currently are or or probably probably very soon as as they're building out AI governance systems. The next question was regarding AI pen tests. what ha the question is what happens when an autonomous agent decides to Ope, let me just squeeze by you into sensitive data that should have been out of scope. More importantly, how do we independently verify that the agent would even report that it happened? So maybe agents passing what might be termed guardrails. 100% honesty, the the the northern boy northern born boy in me just saw a good use case for OPE, OPE. So I I was like, this question is making it in. I love love a good OPE. But But yeah, that that that framework or not framework, that that line of questioning there about AI agents, basically how to how to monitor and and make sure they're doing what they're supposed to be doing.
Walter Haydock: I'll break my response into two pieces. So if an autonomous agent is conducting a penetration test or a red team against a system and it exceeds the limits set by the organization undergoing the test, which we've certainly seen happen with things like OpenAI, where it's agents hacked into Hugging Face, that's definitely a realistic situation. The key things to establish will be what the accountability framework is when such a thing occurs. And then of course preventing it to the extent you can. I'll assume that the organization launching the agent has applied reasonable controls to it, has specified what the rules of engagement of the pen test are, what the outer bounds of the engagement can be. But assuming those are in place and something goes wrong anyway, then ensuring clear accountability is key. I think it's interesting to note that recently Google just changed their terms of service such that if you build an agent on their platform and it impacts a third-party service, Google disclaims any liability for that happening. So they are contractually assigning or denying liability to themselves if a customer belt agent goes off and does something like that. And you're gonna see with all these autonomous penetration testing providers. clear contractual assignment of the accountability if something goes wrong. And that's something that, Stack Aware does in all of our engagements with our customers when we are conducting red teaming, we make clear that we are acting on the information provided to us from our clients. So if the client mistakenly identifies something as being their asset and it's somebody else's asset, and, you know, we get sued, we would we would ask the client to help us in the in the defense. I think is reasonable to to do that. Of course we'd avoid we'd want to avoid any sort of litigation in that case. But yeah, it's important to assign accountability and explain exactly who is specifying the boundaries and what happens if things go wrong. A second piece, a second piece, if an autonomous agent does something that it should not have done, ensuring that you have traceability and auditability of its actions is also really important. And I think a key thing to do is to have deterministic logging that the model cannot necessarily adjust or do anything with. You can observe what an AI agent is doing, you can look at its tool calls, and you don't need to look at it from the perspective of the AI agent. You can look at it from the perspective of the tools that it's calling. So if you see that it invokes a certain MCP server, you can log that on the MCP server side of things. So Stack Aware's MCP server, for example, we log the queries that are made against it, and those are being made by an AI client on the customer side, but the Client on the customer side can't prevent us from logging those queries. And the customer wouldn't want us to anyway, because of this exact reason, so that we could reconstruct exactly what happened over time. And then additionally, you could have the agent in stride logging its decision traces and reasoning explaining why it's taking certain actions. And that is probably going to be higher fidelity than a post facto interrogation, so to speak, of the agent. If you ask why it did something after the fact, it might give you a different response than it would in the midst of conducting the action. So I would say
Cameron Gaudet: Sure.
Walter Haydock: deterministic logging of agent actions and then in stride recording of decision and reasoning traces are key ways to maintain audit auditability.
Cameron Gaudet: could do. Yeah. Yeah. I and I think I think that's a question that by and large a lot of people will have around it. I always I always want to say a shout out to the people that that post the questions and and kind of have these questions. Cause a lot of times people are having the same thoughts or having the same questioning, line of questioning and and thank you for thank you for those of you that are that are asking the questions and putting it out there. The next one
Walter Haydock: And yeah, if I if I don't respond in the LinkedIn comments, I must thank Cameron for going in and being the cleanup crew there and getting all those for this for this brief. So if you're asking questions and I don't get back to you, I'm not ignoring you. Thank you for for for that. And we'll we'll hopefully get into the next aware AI brief.
Cameron Gaudet: Yeah. Yeah, for sure. And and I I'm always I I love being able to see the questions that are that are tied to experience, that are tied to practical use. even even like this next one here, just a just a straight up story about like this happened and and kind of how would you handle it, how would you prevent it, that type of thing. So the next the next question was talking about you had you had a really nice post about people, processes and tools and kind of that. flow as it were in in organizations and and specifically with ai AI governance AI use so someone had commented a vendor they were explaining the situation that they had had a vent a vendor later added ai features that ended up enabled before they had had the opportunity to review them. It violated our company's AI policy so we had to get the vendor to turn them off in a hurry. So the question question for yourself was What have you seen working to get ahead of this? the gap for us was that the capability was already on before we even knew to review it. And then additionally, do you find most vendors expose those settings through an API or is it mostly clicking through admin councils? kind of kind of walking through how you navigate that that type of monitoring when when a vendor is just going to add AI features and you might not find out till well after.
Walter Haydock: Continuous monitoring of your vendors for new feature introduction is table stakes in 2026. An annual review or review done at renewal is not going to cut it because vendors are adding new capabilities all the time. They could be potentially training on data, they could be allowing for autonomous actions that you don't necessarily want happening or you just haven't had the chance to review. Unfortunately, there isn't a great answer here because a lot of vendors are just turning on features by default without even any notification. I posted a while ago about how Slack did that. They have been a little more upfront about giving people notifications before they turn on AI features recently, but monitoring those vendor changelogs, those notifications, those updates to admins is key. On the structured side, on the API side, I have not seen a lot of companies exposing AI configuration settings via API, and they should, but there is a perverse incentive at play here. I'll give an example. Atlassian recently rolled out for I think the bottom two tiers of its customers what it called data contribution, which basically means it's training on all the data in Jira, and they made this the default setting. You had to go in manually via the user interface to disable this to opt out. They did give you a notification, so I'll give them credit there. But there was no way for an admin to do this via API. And certainly, this is the type of thing that StackWare would love to do in a machine readable way. So
Cameron Gaudet: Sure.
Walter Haydock: something that we're looking at doing is actually using tightly scoped agents to go in to
Cameron Gaudet: Sure.
Walter Haydock: our own or customer environments and Tweak those settings via the UI. Now that's it raises some risks in itself. If the if the agent does something that's not supposed to, that could create additional risk. But that's something on the roadmap is looking at getting inside customer environments and monitoring them with our own AI agents.
Cameron Gaudet: Hmm. Yeah, and and that's kind of borne out that that's really fascinating actually. That that's kind of borne out a necessity, right? Like you can't it's it it speaks to the difficulty of of keeping tabs on all these things and keeping and and then the the offered communication, like you said, you know, for Slack or for other for other vendors, but you know, they they might increase that communication when there's a lot of complaints about it not being there in the first place, but it's it's difficult when you're just relying on Relying on that being forthcoming. All right, so the next that was that was the bulk of the questions here. The next couple I put into a little bit of like a feature, I guess I'll say, for this for this podcast here today. with Halloween around the corner. My I've got young kids, I've got all under five, and they are just thrilled about trick-or-treating, right? I think the I think primarily they like the idea of being outside at night and walking in the street. all things that are typically off the table. so I think they're I think that's where a lot of the joy comes from since most of them don't even eat candy yet at this stage. So or or they do it's very, very rationed. but I'm calling this part trust or treat, right? Kind of kind of a play on that. I was thinking about the about trick-or-treating too yesterday and I was it was kind of just a a joke in my mind I guess but thinking about how trick or treating with small kids reminded me of US AI regulation or at least similarities, right? So I'm gonna talk to them about safety and rules. rules that will immediately become fluid in order to to not stifle candy accumulation, right? and then I'll often rely on on their self-reporting and then watch individually as we go through house to house and each of those houses have their own rules, right? So I was like, there's a little bit of a little bit of crossover for There's there's my seamless segue from trick-or-treating into AI governance. Maybe not
Walter Haydock: Ha ha ha.
Cameron Gaudet: so seamless. but here's a here's a couple questions relating or on trust or or perhaps risk treatment, right? Trust or treatment. first question: what is the organization actually accepting when it accepts residual AI risk? Is it accepting the estimated exposure, the uncertainty in that estimate, or both? And I think specifically this question was, this is a little bit of my own my own view of the question, but what point does uncertainty itself, you know, require additional treatment?
Walter Haydock: When you are deciding to accept AI risk or any risk, it's important to be clear about exactly what you're accepting. And the more advanced methodologies, for example, fair factor analysis of information risk, provide a range of outcomes in terms of what could happen to the organization. If you do a Monte Carlo simulation, you can do a thousand runs of an event and get a loss exceedance curve. So that Explicitly tells you what sort of uncertainty you're accepting. Now, that is technically challenging for some folks. So for others, I think a deterministic approach where you're looking at an annual loss expectancy, that could be a fixed number. That might be a more acceptable option for some organizations. And the key is understanding your bounds. Of uncertainty when you're making those decisions. And it certainly could be the case that certain situations require an additional investigation that could form part of the risk treatment. So, for example, a penetration
Cameron Gaudet: Sure.
Walter Haydock: test. A penetration test does not by itself reduce your risk. It merely tells you about risk. So you would look at a system that's undergone quarterly penetration testing for the past five years differently than you would. A system that has never undergone a penetration test. a lot more about the first system than you do the second system.
Cameron Gaudet: Yeah.
Walter Haydock: So you should you should include that in your assessment of the risk. And you know, maybe some of the risk treatment for that second system would be doing just w a one-off penetration test to just understand what the landscape is. So that's how you can tackle uncertainty when it comes to AI risk management.
Cameron Gaudet: Got it. Good deal. and then I failed to mention this is gonna kind of be just a three-piece here of of questioning and then then we'll look to kind of wrap it up. But this these these questions all kind of seem to do with how an how an AI system operates. So I thought they were definitely worthwhile to include here. But the next the next trust or treat question is if every AI agent operates within its approved permissions and risk limits. What would justify accepting or rejecting the risk of the workflow they create together? So again, my kind of editorial view of it is each individual risk within limits, but how how do you make sure that that factors into like overall overall risk scope or or likelihood?
Walter Haydock: When you're combining AI risks, I think it's really important to use a quantitative approach. That's because you can add $10,000 of annual loss expectancy to $10,000 of annual loss expectancy. You cannot add
Cameron Gaudet: Sure.
Walter Haydock: two medium risks. So
Cameron Gaudet: Yeah.
Walter Haydock: if you have two agents that are operating within their defined parameters and permissions, and they are building an application together and you've approved each individually. If you have accepted $10,000 of annual loss expectancy for each, and you have information that they have stayed within the required parameters, you can add those together and decide whether or not the resulting residual risk is or the resulting risk is acceptable. And you know, if need to apply any controls or not. So that I would say is the most important thing to do would be to use a quantitative approach. That way you can legitimately perform arithmetic with. the results of the risk analysis.
Cameron Gaudet: Yeah. That's such a good that's such a good point. Like how do you what does 2x medium risk mean, right? Like it's just it's not something you can do a lot with. So that's a that's a great point. and then lastly, how should an organization determine whether an AI system's original approval still holds as its use, users, data sources, or level of autonomy change? Kind of what should trigger an assessment. Maybe the system itself hasn't changed. But though the environment around
Walter Haydock: When you're looking at an AI system's approval status, certainly regular recurring changes or analyses of the situation are appropriate. At Stack Aware, we do quarterly automated reassessments of every risk identified. And we're looking at accelerating that rate of assessment. And then there are also things that could trigger an immediate reassessment. For example, you are Entering into a business associate agreement with the vendor and now you're processing protected health information. That's the type of thing that would legitimately trigger a risk reassessment. All these things are are important to keep in mind. And there's no one right answer for an organization, but having consistent standards throughout the company will help you make sure that you're making informed decisions.
Cameron Gaudet: Yeah. Yeah, makes sure. Make make or makes a lot of sense to making making sure that it stays kind of congruent within the overall the overall business objectives, right? Too that hope that those probably aren't rapidly changing, but but tying them back to that. So well that's that's the questions I have that were presented here, Walter. again, thank you all for sending questions. Feel free to keep engaging, keep asking questions so we can we can continue practical AI governance discussions and real life scenarios. before I wrap it up though, I I was talking about trick-or-treating. There are three more important questions I must ask, and they have to do with some, let's say, sometimes controversial type of candy that is provided during Halloween. So let me let me get your take on this. This will be the portion of this entire seer podcast that's get that gets clipped and sent to social media, but no. so actual three piece trick-or-treat candy options you can just say yay or nay or you can explain why if if you so choose. Candy cool.
Walter Haydock: Yay.
Cameron Gaudet: Yay, you're in on candy corn. Okay. almond joy. Nay,
Walter Haydock: Day.
Cameron Gaudet: you're out. Okay. And then black licorice.
Walter Haydock: Also nay,
Cameron Gaudet: Also nay. Okay. So one of one out of three. If you're bringing Walter candy for Halloween, just make sure it has candy corn and not I think for myself, I'm I think I'm in on Almond Joy and I think everybody everybody else can have the rest. So yeah.
Walter Haydock: Yeah. Not a candy corn guy?
Cameron Gaudet: Not a big candy corn guy. I'm not a big candy guy in general, or try not to be a big candy guy in general. That's just probably more
Walter Haydock: Yeah. Yeah. Me too. Me too.
Cameron Gaudet: accurate. But but yeah, so maybe as I as I scope through comments, comments for next month's aware AI brief. I expect to see a lot of a lot of candy corn discord to wade through there. So feel free feel free to weigh it with your your preferred choices of those three as well. But again, Walter, thank you so much for joining here today and thank you all for the questions. keep them coming and we'll we'll see you all again next month.
Walter Haydock: Doing well, Cameron. Good to see you again as always.
Cameron Gaudet: Good to see you. Good to see you as well. And and looking forward to maybe the end of October already, which is kind of crazy to crazy to think about already. but but anyways, flying flying right through. I'm always jealous of yourself. We were talking a little bit right before before coming on here about the the cooler temperatures. And this is this is usually a really fun season for for those of you that might live in in areas where the the leaves change color and the temperatures change. We're just we're warm bathwater temp here in in Oklahoma. Not quite, not quite fall, but yeah. Good time of year. Good time of year. But so without out further ado, wanted to get in. We've got actually quite a few questions here that came through came through from this past month. So wanna jump right into it and and kind of dive into some of these some of these queries, some of these topics and and discussion points. So First and foremost, a question had come through via via LinkedIn. How do you get executives to actually show up for management review? I thought that was a really good practical question there.
Walter Haydock: most important thing that compliance, security, privacy, and legal teams can do to get business leaders to show up to AI governance and management reviews is to discuss things that are relevant to them. So if you're coming up with obscure ways of discussing AI-related risk, but you're not really focusing on the business impacts of them, if you're not closely tracking product releases or business expansions, things like that, you're going to lose the attention of executives very quickly. So it's important to align your AI management system to the business's objectives. And ISO 402001 explicitly requires that you do that. So when you're building your AI objectives, when you're building your measurement and monitoring program, it's key to ensure that you're tracking things that are important to the business. Now they may be risk mitigation items, they could be AI accuracy items, there are ways to tackle both the risk side as well as the business side. And that is how you get executives to attend management reviews. I saw another GRC leader actually, and I can call her out because this is public, Linda Fry from Infoblox. She posted that if GRC leaders are making their own dashboards just to satisfy their own needs. and then they expect the business to for some reason just start paying attention to what they're doing, they're gonna be soberly mistaken. So I always recommend using quantitative risk management and measurement to ensure that you're communicating in ways that the business can understand. Cause if you start talking about things like the CVSS score, common vulnerability scoring system, which I think I don't even think security practitioners should use, but let alone business
Cameron Gaudet: Yeah.
Walter Haydock: leaders, if you expect them to worry about what the C VSS score of an item is, then you're going to be sorely mistaken. So I think the zeitgeist is to align security with business objectives. And that's how you get executives to show up for management review.
Cameron Gaudet: Yeah. Yeah. And and tying it to there there was a part of part of my thought process process when I had seen this question was was just how do you have how do you have engaging conversations with anyone, right? You talk about things that they wanna talk about and you put it in terms where there is there is mutual interest and and mutual understanding for sure. So it's it's it's same as same as walking into a room and wanting to carry on a conversation with somebody, be able to be able to talk in ways that that person is then interested in. So very, very good point. The next next question that had come in said, I'll just read this verbatim. If we take the forming, storming, norming, performing cycle, explicit communication, back up, I think this was in reference to a post you had made about explicit communication, but it belongs to the first stage, the forming, and implicit to the last stage, the performing. But how do you move a team through these stages quickly? So maybe how how in practice do you promote and encourage and grow that explicit communication?
Walter Haydock: So, for highly performing organizations, they will use two different types of communication. Explicit communication is I tell you exactly what to do, I have check-ins, I have follow-ups, you confirm when you're done, and then we have a close-out meeting and we say, okay, we're done with this task. Implicit communication cuts out a lot of those steps and only relies on key milestones or indicators along the way. So if I give you a task. Via Jira ticket, then you do the task and you close the ticket. And then I'm automatically notified that you did the task. that you're done. I know that you're done. We all are speaking the same language. We have the same definition of done. We have the same standard operating procedures. There's no confusion as to what happened. So you need to start with explicit communication. You can't skip that. However, the goal would be to maximize the amount of implicit communication that's going on. During any given activity task that the team is conducting. So to accelerate that, you need to run a lot of cycles. That means you can do training exercises, you can do real, you can do stuff for real, you can work on real projects. The faster that you can run that cycle, the faster that you can go through a series of tasks from beginning to end, the more quickly you're going to be able to go from pure explicit to mostly implicit communication. The explicit never goes away, but the more you can rely on implicit, the more efficient you'll be and the faster you will be able to move.
Cameron Gaudet: Yeah. Yeah, makes makes sense because the less the less you have to spend time talking about it, the quicker quicker you're actually gonna be able to do things and and accomplish objectives there. the yeah, go ahead.
Walter Haydock: And some something to add on that on that. So this is I'm gonna tease something that I'm gonna be putting out soon, but something from the Marine Corps that I think is very useful is the five-paragraph order format, which is basically a structured data format. It you could put it in in a JSON, no problem. And it's a way that you explain anything to your team before you're about to execute it. You say, here's situation, here's the mission, here's the execution, here are the administrative and logistical concerns, and here are the communication and signaling requirements for this operation. It's a structured format and it is standardized across the Marine Corps. And what I'm exploring is something called the Vector Framework, which is gonna closely mirror the Marine Corps SMIAC format. Not a very good acronym, by the way.
Cameron Gaudet: Okay.
Walter Haydock: SMEAC. So the the vector framework will allow for the the correct balance between implicit and explicit communication and it'll be useful when communicating with people, but also with AI agents. It will explain what level of delegation is authorized, you know, who's ultimately accountable for the outcome and how to log and record things along the way. So wanted to tease that. Follow me on LinkedIn if you want to see the
Cameron Gaudet: Hm. Yeah. Yeah.
Walter Haydock: the framework when it comes out.
Cameron Gaudet: Right. Yeah. Stay tuned for that, especially especially the gentleman that had the question, but for for all people that are following along and and look forward to look forward to see that. Love love a love good format, love a good framework, right? things that things that can be easily applied. things that are practical. That's the point of this conversation, to have to practicality. So look for that very practical, practical tip coming to a LinkedIn near you. The next question, how do you see organizations handle, maybe more on the experience side of what you've seen, how do you see organizations handle shadow AI in their risk registers when they don't yet have full visibility of what's being used?
Walter Haydock: Risk registers should always tie risks to specific assets. So this is a great question because with shadow AI, you don't necessarily understand what your assets are. Now you could, you should understand what sorts of data you have access to, whether that's customer information, whether that's protected health information, whether that's intellectual property, trade secrets, things like that, which can't be exposed to unintended training, for example. So Start with the data if you don't have a good idea of the assets in use, because that would allow you to do the type of risk assessment that you need to. you can look at the types of risks that could occur without necessarily understanding exactly which systems are in use. So if you are concerned about third-party generative AI providers training on your sensitive data, you wouldn't necessarily say, you know, Chat GPT is training on my sensitive data, but you could say unintended training on this type of customer information is a risk and you can put that in the register and you can make calculations about what you think the likelihood of that occurring is and what the impact of it occurring is.
Cameron Gaudet: Hm. Yeah, it's that's good. Really again, really practical, practical help, practical advice for that. and something that all organizations are going to have to handle, right? That's are going to have to deal with either currently are or or probably probably very soon as as they're building out AI governance systems. The next question was regarding AI pen tests. what ha the question is what happens when an autonomous agent decides to Ope, let me just squeeze by you into sensitive data that should have been out of scope. More importantly, how do we independently verify that the agent would even report that it happened? So maybe agents passing what might be termed guardrails. 100% honesty, the the the northern boy northern born boy in me just saw a good use case for OPE, OPE. So I I was like, this question is making it in. I love love a good OPE. But But yeah, that that that framework or not framework, that that line of questioning there about AI agents, basically how to how to monitor and and make sure they're doing what they're supposed to be doing.
Walter Haydock: I'll break my response into two pieces. So if an autonomous agent is conducting a penetration test or a red team against a system and it exceeds the limits set by the organization undergoing the test, which we've certainly seen happen with things like OpenAI, where it's agents hacked into Hugging Face, that's definitely a realistic situation. The key things to establish will be what the accountability framework is when such a thing occurs. And then of course preventing it to the extent you can. I'll assume that the organization launching the agent has applied reasonable controls to it, has specified what the rules of engagement of the pen test are, what the outer bounds of the engagement can be. But assuming those are in place and something goes wrong anyway, then ensuring clear accountability is key. I think it's interesting to note that recently Google just changed their terms of service such that if you build an agent on their platform and it impacts a third-party service, Google disclaims any liability for that happening. So they are contractually assigning or denying liability to themselves if a customer belt agent goes off and does something like that. And you're gonna see with all these autonomous penetration testing providers. clear contractual assignment of the accountability if something goes wrong. And that's something that, Stack Aware does in all of our engagements with our customers when we are conducting red teaming, we make clear that we are acting on the information provided to us from our clients. So if the client mistakenly identifies something as being their asset and it's somebody else's asset, and, you know, we get sued, we would we would ask the client to help us in the in the defense. I think is reasonable to to do that. Of course we'd avoid we'd want to avoid any sort of litigation in that case. But yeah, it's important to assign accountability and explain exactly who is specifying the boundaries and what happens if things go wrong. A second piece, a second piece, if an autonomous agent does something that it should not have done, ensuring that you have traceability and auditability of its actions is also really important. And I think a key thing to do is to have deterministic logging that the model cannot necessarily adjust or do anything with. You can observe what an AI agent is doing, you can look at its tool calls, and you don't need to look at it from the perspective of the AI agent. You can look at it from the perspective of the tools that it's calling. So if you see that it invokes a certain MCP server, you can log that on the MCP server side of things. So Stack Aware's MCP server, for example, we log the queries that are made against it, and those are being made by an AI client on the customer side, but the Client on the customer side can't prevent us from logging those queries. And the customer wouldn't want us to anyway, because of this exact reason, so that we could reconstruct exactly what happened over time. And then additionally, you could have the agent in stride logging its decision traces and reasoning explaining why it's taking certain actions. And that is probably going to be higher fidelity than a post facto interrogation, so to speak, of the agent. If you ask why it did something after the fact, it might give you a different response than it would in the midst of conducting the action. So I would say
Cameron Gaudet: Sure.
Walter Haydock: deterministic logging of agent actions and then in stride recording of decision and reasoning traces are key ways to maintain audit auditability.
Cameron Gaudet: could do. Yeah. Yeah. I and I think I think that's a question that by and large a lot of people will have around it. I always I always want to say a shout out to the people that that post the questions and and kind of have these questions. Cause a lot of times people are having the same thoughts or having the same questioning, line of questioning and and thank you for thank you for those of you that are that are asking the questions and putting it out there. The next one
Walter Haydock: And yeah, if I if I don't respond in the LinkedIn comments, I must thank Cameron for going in and being the cleanup crew there and getting all those for this for this brief. So if you're asking questions and I don't get back to you, I'm not ignoring you. Thank you for for for that. And we'll we'll hopefully get into the next aware AI brief.
Cameron Gaudet: Yeah. Yeah, for sure. And and I I'm always I I love being able to see the questions that are that are tied to experience, that are tied to practical use. even even like this next one here, just a just a straight up story about like this happened and and kind of how would you handle it, how would you prevent it, that type of thing. So the next the next question was talking about you had you had a really nice post about people, processes and tools and kind of that. flow as it were in in organizations and and specifically with ai AI governance AI use so someone had commented a vendor they were explaining the situation that they had had a vent a vendor later added ai features that ended up enabled before they had had the opportunity to review them. It violated our company's AI policy so we had to get the vendor to turn them off in a hurry. So the question question for yourself was What have you seen working to get ahead of this? the gap for us was that the capability was already on before we even knew to review it. And then additionally, do you find most vendors expose those settings through an API or is it mostly clicking through admin councils? kind of kind of walking through how you navigate that that type of monitoring when when a vendor is just going to add AI features and you might not find out till well after.
Walter Haydock: Continuous monitoring of your vendors for new feature introduction is table stakes in 2026. An annual review or review done at renewal is not going to cut it because vendors are adding new capabilities all the time. They could be potentially training on data, they could be allowing for autonomous actions that you don't necessarily want happening or you just haven't had the chance to review. Unfortunately, there isn't a great answer here because a lot of vendors are just turning on features by default without even any notification. I posted a while ago about how Slack did that. They have been a little more upfront about giving people notifications before they turn on AI features recently, but monitoring those vendor changelogs, those notifications, those updates to admins is key. On the structured side, on the API side, I have not seen a lot of companies exposing AI configuration settings via API, and they should, but there is a perverse incentive at play here. I'll give an example. Atlassian recently rolled out for I think the bottom two tiers of its customers what it called data contribution, which basically means it's training on all the data in Jira, and they made this the default setting. You had to go in manually via the user interface to disable this to opt out. They did give you a notification, so I'll give them credit there. But there was no way for an admin to do this via API. And certainly, this is the type of thing that StackWare would love to do in a machine readable way. So
Cameron Gaudet: Sure.
Walter Haydock: something that we're looking at doing is actually using tightly scoped agents to go in to
Cameron Gaudet: Sure.
Walter Haydock: our own or customer environments and Tweak those settings via the UI. Now that's it raises some risks in itself. If the if the agent does something that's not supposed to, that could create additional risk. But that's something on the roadmap is looking at getting inside customer environments and monitoring them with our own AI agents.
Cameron Gaudet: Hmm. Yeah, and and that's kind of borne out that that's really fascinating actually. That that's kind of borne out a necessity, right? Like you can't it's it it speaks to the difficulty of of keeping tabs on all these things and keeping and and then the the offered communication, like you said, you know, for Slack or for other for other vendors, but you know, they they might increase that communication when there's a lot of complaints about it not being there in the first place, but it's it's difficult when you're just relying on Relying on that being forthcoming. All right, so the next that was that was the bulk of the questions here. The next couple I put into a little bit of like a feature, I guess I'll say, for this for this podcast here today. with Halloween around the corner. My I've got young kids, I've got all under five, and they are just thrilled about trick-or-treating, right? I think the I think primarily they like the idea of being outside at night and walking in the street. all things that are typically off the table. so I think they're I think that's where a lot of the joy comes from since most of them don't even eat candy yet at this stage. So or or they do it's very, very rationed. but I'm calling this part trust or treat, right? Kind of kind of a play on that. I was thinking about the about trick-or-treating too yesterday and I was it was kind of just a a joke in my mind I guess but thinking about how trick or treating with small kids reminded me of US AI regulation or at least similarities, right? So I'm gonna talk to them about safety and rules. rules that will immediately become fluid in order to to not stifle candy accumulation, right? and then I'll often rely on on their self-reporting and then watch individually as we go through house to house and each of those houses have their own rules, right? So I was like, there's a little bit of a little bit of crossover for There's there's my seamless segue from trick-or-treating into AI governance. Maybe not
Walter Haydock: Ha ha ha.
Cameron Gaudet: so seamless. but here's a here's a couple questions relating or on trust or or perhaps risk treatment, right? Trust or treatment. first question: what is the organization actually accepting when it accepts residual AI risk? Is it accepting the estimated exposure, the uncertainty in that estimate, or both? And I think specifically this question was, this is a little bit of my own my own view of the question, but what point does uncertainty itself, you know, require additional treatment?
Walter Haydock: When you are deciding to accept AI risk or any risk, it's important to be clear about exactly what you're accepting. And the more advanced methodologies, for example, fair factor analysis of information risk, provide a range of outcomes in terms of what could happen to the organization. If you do a Monte Carlo simulation, you can do a thousand runs of an event and get a loss exceedance curve. So that Explicitly tells you what sort of uncertainty you're accepting. Now, that is technically challenging for some folks. So for others, I think a deterministic approach where you're looking at an annual loss expectancy, that could be a fixed number. That might be a more acceptable option for some organizations. And the key is understanding your bounds. Of uncertainty when you're making those decisions. And it certainly could be the case that certain situations require an additional investigation that could form part of the risk treatment. So, for example, a penetration
Cameron Gaudet: Sure.
Walter Haydock: test. A penetration test does not by itself reduce your risk. It merely tells you about risk. So you would look at a system that's undergone quarterly penetration testing for the past five years differently than you would. A system that has never undergone a penetration test. a lot more about the first system than you do the second system.
Cameron Gaudet: Yeah.
Walter Haydock: So you should you should include that in your assessment of the risk. And you know, maybe some of the risk treatment for that second system would be doing just w a one-off penetration test to just understand what the landscape is. So that's how you can tackle uncertainty when it comes to AI risk management.
Cameron Gaudet: Got it. Good deal. and then I failed to mention this is gonna kind of be just a three-piece here of of questioning and then then we'll look to kind of wrap it up. But this these these questions all kind of seem to do with how an how an AI system operates. So I thought they were definitely worthwhile to include here. But the next the next trust or treat question is if every AI agent operates within its approved permissions and risk limits. What would justify accepting or rejecting the risk of the workflow they create together? So again, my kind of editorial view of it is each individual risk within limits, but how how do you make sure that that factors into like overall overall risk scope or or likelihood?
Walter Haydock: When you're combining AI risks, I think it's really important to use a quantitative approach. That's because you can add $10,000 of annual loss expectancy to $10,000 of annual loss expectancy. You cannot add
Cameron Gaudet: Sure.
Walter Haydock: two medium risks. So
Cameron Gaudet: Yeah.
Walter Haydock: if you have two agents that are operating within their defined parameters and permissions, and they are building an application together and you've approved each individually. If you have accepted $10,000 of annual loss expectancy for each, and you have information that they have stayed within the required parameters, you can add those together and decide whether or not the resulting residual risk is or the resulting risk is acceptable. And you know, if need to apply any controls or not. So that I would say is the most important thing to do would be to use a quantitative approach. That way you can legitimately perform arithmetic with. the results of the risk analysis.
Cameron Gaudet: Yeah. That's such a good that's such a good point. Like how do you what does 2x medium risk mean, right? Like it's just it's not something you can do a lot with. So that's a that's a great point. and then lastly, how should an organization determine whether an AI system's original approval still holds as its use, users, data sources, or level of autonomy change? Kind of what should trigger an assessment. Maybe the system itself hasn't changed. But though the environment around
Walter Haydock: When you're looking at an AI system's approval status, certainly regular recurring changes or analyses of the situation are appropriate. At Stack Aware, we do quarterly automated reassessments of every risk identified. And we're looking at accelerating that rate of assessment. And then there are also things that could trigger an immediate reassessment. For example, you are Entering into a business associate agreement with the vendor and now you're processing protected health information. That's the type of thing that would legitimately trigger a risk reassessment. All these things are are important to keep in mind. And there's no one right answer for an organization, but having consistent standards throughout the company will help you make sure that you're making informed decisions.
Cameron Gaudet: Yeah. Yeah, makes sure. Make make or makes a lot of sense to making making sure that it stays kind of congruent within the overall the overall business objectives, right? Too that hope that those probably aren't rapidly changing, but but tying them back to that. So well that's that's the questions I have that were presented here, Walter. again, thank you all for sending questions. Feel free to keep engaging, keep asking questions so we can we can continue practical AI governance discussions and real life scenarios. before I wrap it up though, I I was talking about trick-or-treating. There are three more important questions I must ask, and they have to do with some, let's say, sometimes controversial type of candy that is provided during Halloween. So let me let me get your take on this. This will be the portion of this entire seer podcast that's get that gets clipped and sent to social media, but no. so actual three piece trick-or-treat candy options you can just say yay or nay or you can explain why if if you so choose. Candy cool.
Walter Haydock: Yay.
Cameron Gaudet: Yay, you're in on candy corn. Okay. almond joy. Nay,
Walter Haydock: Day.
Cameron Gaudet: you're out. Okay. And then black licorice.
Walter Haydock: Also nay,
Cameron Gaudet: Also nay. Okay. So one of one out of three. If you're bringing Walter candy for Halloween, just make sure it has candy corn and not I think for myself, I'm I think I'm in on Almond Joy and I think everybody everybody else can have the rest. So yeah.
Walter Haydock: Yeah. Not a candy corn guy?
Cameron Gaudet: Not a big candy corn guy. I'm not a big candy guy in general, or try not to be a big candy guy in general. That's just probably more
Walter Haydock: Yeah. Yeah. Me too. Me too.
Cameron Gaudet: accurate. But but yeah, so maybe as I as I scope through comments, comments for next month's aware AI brief. I expect to see a lot of a lot of candy corn discord to wade through there. So feel free feel free to weigh it with your your preferred choices of those three as well. But again, Walter, thank you so much for joining here today and thank you all for the questions. keep them coming and we'll we'll see you all again next month.
