[{"content":"","date":"31 October 2026","externalUrl":null,"permalink":"/tags/ai/","section":"Tags","summary":"","title":"AI","type":"tags"},{"content":"Zero Trust: What It Really Means\nZero Trust has dominated cybersecurity conversations for a decade. For some, it\u0026rsquo;s an architecture or strategy; for others, it\u0026rsquo;s a product, a set of controls, or merely a buzzword.\nBut if you peel back all the marketing hype, Zero Trust is actually pretty simple: just because something is in the building, has been around for a while, or looks friendly doesn’t mean it should get access. Every request to do something—whether it’s a person, a device, or an AI—should be checked for who it is, what it\u0026rsquo;s trying to do, and whether it actually makes sense. In other words, trust, but verify, and then verify again.\nWhy AI Needs Zero Trust\nAI is arguably the ultimate insider threat—not because it’s planning world domination, but because it can process, recall, and connect information far beyond human capacity, and work nonstop. Give it too much access, and you’ve built the perfect insider.\nThis is exactly the kind of digital mess that Zero Trust was invented to clean up—like a cybersecurity Roomba, but with fewer beeps and more policies.\nAI doesn’t need a new security philosophy or another framework. We just need to apply the security ideas we already have.\nIdentity Is the Foundation\nAt the heart of Zero Trust is identity. If you don’t know who (or what) you’re dealing with, you’re handing out keys to strangers at a masquerade party.\nBefore you let a user, device, application, or AI agent do anything, you need to know exactly who or what you’re dealing with. That’s why I always say every AI needs its own badge number—just like the rest of us. Giving each AI a unique identity lets us track who’s doing what, hand out the right permissions, keep an eye on activity, and, if things go sideways, pull the plug before the AI starts redecorating your data center.\nIf you’ve got five AI agents all using the same generic service account, you’ve already broken Zero Trust before the fun even starts. You can’t make smart decisions about access if you don’t know which AI is actually knocking on the door.\nFrom Identity to Permissions\nOnce you know who (or what) you’re dealing with, the next question is: what is this AI actually allowed to do?\nThis is where ‘least privilege’ matters. Just because a Finance AI could access Security data doesn’t mean it should. A Security AI shouldn’t see HR info just because its creator could. Customer support AI doesn’t need admin rights for rare edge cases.\nZero Trust is all about being specific: a particular identity gets access to a particular thing, for a particular reason, under particular circumstances. AI shouldn’t get a free pass here—it needs to play by the same rules.\nA common mistake: approving an AI platform doesn’t mean approving every agent, connector, or workflow built on it. Each component needs its own scrutiny.\nApproving Microsoft 365 does not mean every employee gets Global Administrator. Approving an AI platform shouldn’t mean every AI gets to do everything, everywhere, all at once. Trust should be about specific access decisions, not just the logo on the box.\nThe Role of Context\nZero Trust also leans hard on context. Even if you know who someone is, they can still do something risky. For example, an employee logging in from their work laptop at 10am is one thing; trying to get admin access from a random device in another country at 3am is quite another.\nThe person didn’t change—the situation did.\nAI needs the same kind of context check. Who kicked off the request? Which agent is doing the work? What info is it after? What’s it trying to do? Is this normal for that agent, or is it suddenly acting weird? Is sensitive data involved? Does a human need to sign off?\nThese questions turn identity from just a name tag into a real security decision.\nAI Workflow Chains: Why Every Step Matters\nThis matters even more because an AI workflow can bounce across a bunch of systems in seconds. One user request might have an AI searching a knowledge base, calling an API, grabbing customer data, opening a ticket, updating a database, and firing off a message—all before you’ve finished your coffee.\nTo the user, it just looks like one simple interaction—like ordering a coffee and not seeing the chaos happening behind the counter.\nBut from a Zero Trust perspective, it’s a whole chain of access decisions happening behind the scenes.\nEvery link in that chain counts. The research agent needs permission to grab a document. The orchestration agent needs permission to call the research agent. The action agent needs the OK to create a ticket. The ticketing system should know exactly who did what. And ideally, you should be able to trace the whole thing back to the human who started it all.\nIf one agent calls another agent, trust should not simply flow downstream like water through a pipe. Authorization has to survive the chain.\nOtherwise, one overly trusted AI agent can become the shortcut that blows past all those security boundaries you’ve spent the last decade building.\nWe already have a name for setups where everything can talk to everything else: flat networks.\nAnd we’ve spent years trying to get rid of those—with mixed results.\nLet’s not accidentally rebuild them out of APIs.\nSegmentation for AI\nThat’s why segmentation is just as important in AI as it is in networking. Not every AI should talk to every system. Not every agent should call every other agent. Not every workflow needs the keys to every tool in the toolbox.\nRole-specific AI is a great way to draw those lines. Finance AI stays in the Finance lane. Security AI sticks to Security. HR AI minds its own business. This is basically micro-segmentation, but for AI—putting up cubicle walls for your digital coworkers so they don’t wander off and start answering HR emails with cat memes. When AI crosses into another lane, it should be on purpose, with permission, and easy to see.\nThis is basically micro-segmentation, but for AI.\nInstead of asking which network segment a workload can reach, we’ll be asking which data sources, APIs, tools, agents, apps, and actions an AI identity can touch.\nSame idea, just different pipes.\nTrust Isn’t Forever: Continuous Verification\nAnother big Zero Trust rule: trust isn’t forever. That’s going to be a huge deal for AI governance.\nAn AI agent might be reliable today, but updates or changes to models, prompts, connectors, or tools can quickly alter behavior and risk.\nSo, we can’t just trust an AI because it passed a security review when it first showed up. Testing something six months ago is not continuous verification.\nOrganizations need to monitor AI over time, continuously collecting evidence that each agent remains trustworthy within its assigned boundaries. Automation doesn’t mean approving every action, but it does mean ongoing verification.\nAnd that evidence can go both ways.\nIf an AI keeps doing a low-risk job correctly, inside clear boundaries and with good monitoring, maybe it gets a little more freedom. Trust is something it earns, not something it gets for free.\nIf an AI starts acting up, restrict its access as needed—like putting it in the penalty box until it earns back trust.\nIn security terminology, access becomes restricted. In regular employee terms, the AI just got put back on probation. Either way, the system adjusts based on risk. It responds to risk.\nVisibility and Auditability\nVisibility is another big test: did you actually implement Zero Trust, or did you buy something with Zero Trust on the label? You can’t keep tabs on what you can’t see.\nAI audit records need to do more than record the user prompt. We should know which AI did what, what it accessed, what info it grabbed, what tools it used, what it tried to do, whether it worked, and who kicked off the whole thing. This is particularly important within multi-agent environments. Imagine a user asks Agent A to perform a task. Agent A invokes Agent B. Agent B retrieves the information. Agent C performs the actual action. If the audit trail says “AI activity occurred,” congratulations: you have successfully logged almost nothing useful.\nTraceability really matters.\nZero Trust means checking every step, so your AI setup needs to track identity and permissions through the entire workflow.\nData Access: Why Context and Timing Matter\nData itself also deserves attention. AI systems are always hungry for greater context. The quickest way to make them smarter is to feed them more info: more documents, more databases, more APIs, more email, more collaboration platforms. The list never ends.\nZero Trust flips the script and asks: why does this AI (or person) need this specific data right now?\nAnd ‘right now’ is the key part.\nEven if an AI is allowed into a data repository, it doesn’t mean it needs access to everything in there for every task. This is where notions like just-in-time access come in handy for AI. An AI agent could get temporary extra permissions for a specific approved job, and then lose them right after. Humans already use Privileged Access Management for this. There’s no reason AI can’t do the same. In fact, AI might be even better at this, since you can usually define exactly what a machine task should be allowed to do.\nTake an infrastructure AI, for example. It doesn’t need permanent permission to restart production services. Instead, it could get the green light to restart one specific service after an approved change, during a maintenance window, and then lose that permission as soon as the job’s done.\nThat’s Zero Trust in action for autonomous systems.\nManaging Credentials and Secrets\nAI agents shouldn’t have permanent credentials just because someone pasted them in to get a proof of concept working six months ago on a random Tuesday.\nWhere it makes sense, use short-lived tokens, managed identities, workload authentication, vault-backed credentials, restricted scopes, and anything else that makes stolen or misused secrets less valuable.\nNothing undermines Zero Trust like old, forgotten API keys left in code, protected only by hope.\nPolicy vs. Enforcement\nAI forces us to rethink the disparity between policy and enforcement.\nHistorically, security policies frequently describe what people are supposed to do. Zero Trust moves more of that enforcement into technology, and AI guardrails ought to follow the same philosophy.\nIf an AI isn’t supposed to send external email, don’t just tell it not to in the system prompt.\nThe system shouldn’t even have that ability in the first place.\nIf an AI can’t approve payments over a certain amount, the app or workflow should enforce that. If it shouldn’t see HR data, its identity shouldn’t have permission to get HR data. Simple as that.\nA policy statement is nice. A denied API call is even better.\nZero Trust: Expect Things to Go Wrong\nZero Trust’s lesson for AI: assume things will go wrong—prompts can be tricked, users err, and software surprises. The goal is to set up access boundaries so that one slip-up doesn’t turn into a disaster. Zero Trust is about minimizing risk: strict identity checks, least access, constant monitoring, and expecting failure.\nAI doesn’t change any of those rules. If anything, AI makes them even easier to understand.\nAI might finally push organizations to actually build the identity-focused security setups they’ve been talking about for years. AI agents don’t fit neatly into the old idea of being ‘inside’ or ‘outside’ the network. They can run in the cloud, call APIs across several SaaS platforms, pull info from all over, and do things for users anywhere on the planet.\nWhere something is on the network doesn’t tell you much about whether you should trust it. Identity tells you a whole lot more. Who’s the agent? Who started the request? What’s their job? What data can they see? What are they trying to do? What’s the risk right now? Those are the questions Zero Trust is all about.\nAnd they’re also the questions you need for AI governance.\nThat overlap isn’t a coincidence.\nAI is really an identity problem, and Zero Trust is all about identity. They’re made for each other.\nBuilding Trust, Not Just Barriers\nThe goal isn’t to distrust AI forever. The goal is to build an environment where trust is specific, measurable, revocable, and backed by real evidence. That keeps things safer for people, for organizations, and even for the machines themselves.\nAnd that’s only going to get more important as organizations move toward a scenario where hundreds or thousands of AI workers work right alongside humans.\nBecause once AI gets treated as an identity under Zero Trust, something else starts to shift: the organization itself.\nDepartments may soon mix humans and AI, with managers supervising both and work shifting based on skills, permissions, and risk—not just job titles.\nThe org chart will get weird—imagine staff meetings at which digital assistants argue over the last donut.\nI’m here for it.\nThat’s where we go next.\n","date":"31 October 2026","externalUrl":null,"permalink":"/posts/ai-doesnt-need-zero-trust.-it-is-zero-trust/","section":"Archives","summary":"","title":"AI Doesn’t Need Zero Trust. It Is Zero Trust","type":"posts"},{"content":"Zero Trust: What It Really Means\nZero Trust has dominated cybersecurity conversations for a decade. For some, it\u0026rsquo;s an architecture or strategy; for others, it\u0026rsquo;s a product, a set of controls, or merely a buzzword.\nBut if you peel back all the marketing hype, Zero Trust is actually pretty simple: just because something is in the building, has been around for a while, or looks friendly doesn’t mean it should get access. Every request to do something—whether it’s a person, a device, or an AI—should be checked for who it is, what it\u0026rsquo;s trying to do, and whether it actually makes sense. In other words, trust, but verify, and then verify again.\nWhy AI Needs Zero Trust\nAI is arguably the ultimate insider threat—not because it’s planning world domination, but because it can process, recall, and connect information far beyond human capacity, and work nonstop. Give it too much access, and you’ve built the perfect insider.\nThis is exactly the kind of digital mess that Zero Trust was invented to clean up—like a cybersecurity Roomba, but with fewer beeps and more policies.\nAI doesn’t need a new security philosophy or another framework. We just need to apply the security ideas we already have.\nIdentity Is the Foundation\nAt the heart of Zero Trust is identity. If you don’t know who (or what) you’re dealing with, you’re handing out keys to strangers at a masquerade party.\nBefore you let a user, device, application, or AI agent do anything, you need to know exactly who or what you’re dealing with. That’s why I always say every AI needs its own badge number—just like the rest of us. Giving each AI a unique identity lets us track who’s doing what, hand out the right permissions, keep an eye on activity, and, if things go sideways, pull the plug before the AI starts redecorating your data center.\nIf you’ve got five AI agents all using the same generic service account, you’ve already broken Zero Trust before the fun even starts. You can’t make smart decisions about access if you don’t know which AI is actually knocking on the door.\nFrom Identity to Permissions\nOnce you know who (or what) you’re dealing with, the next question is: what is this AI actually allowed to do?\nThis is where ‘least privilege’ matters. Just because a Finance AI could access Security data doesn’t mean it should. A Security AI shouldn’t see HR info just because its creator could. Customer support AI doesn’t need admin rights for rare edge cases.\nZero Trust is all about being specific: a particular identity gets access to a particular thing, for a particular reason, under particular circumstances. AI shouldn’t get a free pass here—it needs to play by the same rules.\nA common mistake: approving an AI platform doesn’t mean approving every agent, connector, or workflow built on it. Each component needs its own scrutiny.\nApproving Microsoft 365 does not mean every employee gets Global Administrator. Approving an AI platform shouldn’t mean every AI gets to do everything, everywhere, all at once. Trust should be about specific access decisions, not just the logo on the box.\nThe Role of Context\nZero Trust also leans hard on context. Even if you know who someone is, they can still do something risky. For example, an employee logging in from their work laptop at 10am is one thing; trying to get admin access from a random device in another country at 3am is quite another.\nThe person didn’t change—the situation did.\nAI needs the same kind of context check. Who kicked off the request? Which agent is doing the work? What info is it after? What’s it trying to do? Is this normal for that agent, or is it suddenly acting weird? Is sensitive data involved? Does a human need to sign off?\nThese questions turn identity from just a name tag into a real security decision.\nAI Workflow Chains: Why Every Step Matters\nThis matters even more because an AI workflow can bounce across a bunch of systems in seconds. One user request might have an AI searching a knowledge base, calling an API, grabbing customer data, opening a ticket, updating a database, and firing off a message—all before you’ve finished your coffee.\nTo the user, it just looks like one simple interaction—like ordering a coffee and not seeing the chaos happening behind the counter.\nBut from a Zero Trust perspective, it’s a whole chain of access decisions happening behind the scenes.\nEvery link in that chain counts. The research agent needs permission to grab a document. The orchestration agent needs permission to call the research agent. The action agent needs the OK to create a ticket. The ticketing system should know exactly who did what. And ideally, you should be able to trace the whole thing back to the human who started it all.\nIf one agent calls another agent, trust should not simply flow downstream like water through a pipe. Authorization has to survive the chain.\nOtherwise, one overly trusted AI agent can become the shortcut that blows past all those security boundaries you’ve spent the last decade building.\nWe already have a name for setups where everything can talk to everything else: flat networks.\nAnd we’ve spent years trying to get rid of those—with mixed results.\nLet’s not accidentally rebuild them out of APIs.\nSegmentation for AI\nThat’s why segmentation is just as important in AI as it is in networking. Not every AI should talk to every system. Not every agent should call every other agent. Not every workflow needs the keys to every tool in the toolbox.\nRole-specific AI is a great way to draw those lines. Finance AI stays in the Finance lane. Security AI sticks to Security. HR AI minds its own business. This is basically micro-segmentation, but for AI—putting up cubicle walls for your digital coworkers so they don’t wander off and start answering HR emails with cat memes. When AI crosses into another lane, it should be on purpose, with permission, and easy to see.\nThis is basically micro-segmentation, but for AI.\nInstead of asking which network segment a workload can reach, we’ll be asking which data sources, APIs, tools, agents, apps, and actions an AI identity can touch.\nSame idea, just different pipes.\nTrust Isn’t Forever: Continuous Verification\nAnother big Zero Trust rule: trust isn’t forever. That’s going to be a huge deal for AI governance.\nAn AI agent might be reliable today, but updates or changes to models, prompts, connectors, or tools can quickly alter behavior and risk.\nSo, we can’t just trust an AI because it passed a security review when it first showed up. Testing something six months ago is not continuous verification.\nOrganizations need to monitor AI over time, continuously collecting evidence that each agent remains trustworthy within its assigned boundaries. Automation doesn’t mean approving every action, but it does mean ongoing verification.\nAnd that evidence can go both ways.\nIf an AI keeps doing a low-risk job correctly, inside clear boundaries and with good monitoring, maybe it gets a little more freedom. Trust is something it earns, not something it gets for free.\nIf an AI starts acting up, restrict its access as needed—like putting it in the penalty box until it earns back trust.\nIn security terminology, access becomes restricted. In regular employee terms, the AI just got put back on probation. Either way, the system adjusts based on risk. It responds to risk.\nVisibility and Auditability\nVisibility is another big test: did you actually implement Zero Trust, or did you buy something with Zero Trust on the label? You can’t keep tabs on what you can’t see.\nAI audit records need to do more than record the user prompt. We should know which AI did what, what it accessed, what info it grabbed, what tools it used, what it tried to do, whether it worked, and who kicked off the whole thing. This is particularly important within multi-agent environments. Imagine a user asks Agent A to perform a task. Agent A invokes Agent B. Agent B retrieves the information. Agent C performs the actual action. If the audit trail says “AI activity occurred,” congratulations: you have successfully logged almost nothing useful.\nTraceability really matters.\nZero Trust means checking every step, so your AI setup needs to track identity and permissions through the entire workflow.\nData Access: Why Context and Timing Matter\nData itself also deserves attention. AI systems are always hungry for greater context. The quickest way to make them smarter is to feed them more info: more documents, more databases, more APIs, more email, more collaboration platforms. The list never ends.\nZero Trust flips the script and asks: why does this AI (or person) need this specific data right now?\nAnd ‘right now’ is the key part.\nEven if an AI is allowed into a data repository, it doesn’t mean it needs access to everything in there for every task. This is where notions like just-in-time access come in handy for AI. An AI agent could get temporary extra permissions for a specific approved job, and then lose them right after. Humans already use Privileged Access Management for this. There’s no reason AI can’t do the same. In fact, AI might be even better at this, since you can usually define exactly what a machine task should be allowed to do.\nTake an infrastructure AI, for example. It doesn’t need permanent permission to restart production services. Instead, it could get the green light to restart one specific service after an approved change, during a maintenance window, and then lose that permission as soon as the job’s done.\nThat’s Zero Trust in action for autonomous systems.\nManaging Credentials and Secrets\nAI agents shouldn’t have permanent credentials just because someone pasted them in to get a proof of concept working six months ago on a random Tuesday.\nWhere it makes sense, use short-lived tokens, managed identities, workload authentication, vault-backed credentials, restricted scopes, and anything else that makes stolen or misused secrets less valuable.\nNothing undermines Zero Trust like old, forgotten API keys left in code, protected only by hope.\nPolicy vs. Enforcement\nAI forces us to rethink the disparity between policy and enforcement.\nHistorically, security policies frequently describe what people are supposed to do. Zero Trust moves more of that enforcement into technology, and AI guardrails ought to follow the same philosophy.\nIf an AI isn’t supposed to send external email, don’t just tell it not to in the system prompt.\nThe system shouldn’t even have that ability in the first place.\nIf an AI can’t approve payments over a certain amount, the app or workflow should enforce that. If it shouldn’t see HR data, its identity shouldn’t have permission to get HR data. Simple as that.\nA policy statement is nice. A denied API call is even better.\nZero Trust: Expect Things to Go Wrong\nZero Trust’s lesson for AI: assume things will go wrong—prompts can be tricked, users err, and software surprises. The goal is to set up access boundaries so that one slip-up doesn’t turn into a disaster. Zero Trust is about minimizing risk: strict identity checks, least access, constant monitoring, and expecting failure.\nAI doesn’t change any of those rules. If anything, AI makes them even easier to understand.\nAI might finally push organizations to actually build the identity-focused security setups they’ve been talking about for years. AI agents don’t fit neatly into the old idea of being ‘inside’ or ‘outside’ the network. They can run in the cloud, call APIs across several SaaS platforms, pull info from all over, and do things for users anywhere on the planet.\nWhere something is on the network doesn’t tell you much about whether you should trust it. Identity tells you a whole lot more. Who’s the agent? Who started the request? What’s their job? What data can they see? What are they trying to do? What’s the risk right now? Those are the questions Zero Trust is all about.\nAnd they’re also the questions you need for AI governance.\nThat overlap isn’t a coincidence.\nAI is really an identity problem, and Zero Trust is all about identity. They’re made for each other.\nBuilding Trust, Not Just Barriers\nThe goal isn’t to distrust AI forever. The goal is to build an environment where trust is specific, measurable, revocable, and backed by real evidence. That keeps things safer for people, for organizations, and even for the machines themselves.\nAnd that’s only going to get more important as organizations move toward a scenario where hundreds or thousands of AI workers work right alongside humans.\nBecause once AI gets treated as an identity under Zero Trust, something else starts to shift: the organization itself.\nDepartments may soon mix humans and AI, with managers supervising both and work shifting based on skills, permissions, and risk—not just job titles.\nThe org chart will get weird—imagine staff meetings at which digital assistants argue over the last donut.\nI’m here for it.\nThat’s where we go next.\n","date":"31 October 2026","externalUrl":null,"permalink":"/posts/ai-doesnt-need-zero-trust.-it-is-zero-trust./","section":"Archives","summary":"","title":"AI Doesn’t Need Zero Trust. It Is Zero Trust.","type":"posts"},{"content":"","date":"31 October 2026","externalUrl":null,"permalink":"/posts/","section":"Archives","summary":"","title":"Archives","type":"posts"},{"content":"","date":"31 October 2026","externalUrl":null,"permalink":"/tags/business/","section":"Tags","summary":"","title":"Business","type":"tags"},{"content":"","date":"31 October 2026","externalUrl":null,"permalink":"/tags/cyberbunny74/","section":"Tags","summary":"","title":"CyberBunny74","type":"tags"},{"content":"","date":"31 October 2026","externalUrl":null,"permalink":"/","section":"New England Cyber","summary":"","title":"New England Cyber","type":"page"},{"content":"","date":"31 October 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"The phrase “insider threat” tends to make people imagine something dramatic. A disgruntled employee copying confidential files before leaving. Someone stealing intellectual property. A contractor deliberately abusing privileged access. Perhaps there is a USB drive involved, because cybersecurity presentations seem legally required to include at least one suspicious USB drive.\nSure, those dramatic incidents do happen, but most insider risk is a lot less Hollywood and a lot more \u0026lsquo;oops, did I just send that to the wrong person?\u0026rsquo;\nPeople make mistakes. They send information to the wrong recipient. They upload a document to the wrong service. They access more data than they need. They misunderstand a policy. They accidentally share sensitive information with someone who should not see it.\nIntent is important, but you don’t need a villain twirling their mustache for things to go wrong.\nThat’s what makes AI such an interesting character in the insider-risk story.\nAI isn’t out to get you. At least, your meeting note summarizer probably isn’t secretly planning world domination between prompts. But here’s the thing: most employees who cause security incidents aren’t evil masterminds either. The real danger isn’t always about intent.\nSometimes, the real risk is what happens when you mix a lot of capability with a lot of access—think peanut butter and jelly, but for security headaches.\nAnd AI has a lot of capability.\nIn the previous article, I argued that every AI worker should have a unique identity—a digital badge number. Once we give that identity access to organizational systems and information, we need to think seriously about what that new insider can see, retrieve, and do.\nA human employee can only read so fast. Even your most caffeinated team member can’t possibly search every document, review every email, cross-reference every spreadsheet, and remember every little detail from years of company history.\nAI, on the other hand, can—and does it before you’ve finished your first cup of coffee.\nAn employee may have access to thousands of documents and never open most of them. An AI system can search through those documents in seconds. A person may not recognize that information stored in three separate systems becomes highly sensitive when combined. AI is specifically designed to make those connections. A human may forget something they read six months ago. An AI can retrieve it instantly as long as the information remains available.Maybe ten, if you’re lucky enough to have your calendar hijacked by consecutive meetings. Depending on how many meetings somebody scheduled.\nAI, meanwhile, doesn’t need coffee breaks, bathroom breaks, or even sleep. It just keeps going.\nPut it all together, and suddenly the insider-risk equation starts to look a lot different.\nImagine hiring someone who has access to almost everything, remembers every detail perfectly, reads faster than a speeding bullet, and can connect dots among departments—except they have no gut feeling about what information should or shouldn’t be mixed together unless you spell it out for them.\nYou’d probably want to put a few guardrails around that kind of employee, right?\nWell, congratulations, because that’s basically what we’re building with AI.\nAI does not need to “steal” information in the traditional sense. It can expose sensitive data simply by answering a question accurately.\nSuppose an employee asks an enterprise AI, “Why is Project Atlas delayed?” The AI searches project documentation, meeting transcripts, budget records, email, and perhaps HR information. It returns an excellent summary explaining that the project lost two engineers, a manager is on leave, a vendor missed a major deadline, and the budget was reduced following an executive decision.\nEvery statement may be completely accurate.\nThe response may also contain information the employee should never have received.\nThe AI did not break into anything. It did not bypass an access control. It did not exploit a vulnerability. It did exactly what we designed it to do using the permissions we gave it.\nThat’s what makes the whole AI insider risk thing a little squirm-inducing.\nTraditional cybersecurity often focuses heavily on unauthorized access. Someone gets into something they should not be able to reach, and security detects or prevents it.\nAI can create problems through authorized access used in ways nobody anticipated.\nThat is why least privilege matters so much.\nIf an AI should not know something, the strongest control is not hoping the model refuses to answer. The strongest control is preventing the AI identity from retrieving that information in the first place.\nPrompt guardrails help. Data-loss-prevention controls help. Content filters help. Monitoring helps.\nBut at the end of the day, it all starts with access.\nThe smartest AI in the world cannot summarize a document it cannot retrieve.\nThe same issue appears with correlation.\nOrganizations often secure sensitive information by separating it across systems, departments, repositories, and documents. Each piece of information may seem harmless on its own.\nAI flips that whole equation on its head.\nA list of server names might not be particularly sensitive. A vulnerability report may be more restricted. A network diagram may live in another system. A vendor list may be available somewhere else. Each piece has its own level of sensitivity.\nCombined, they may tell a very different story.\nCybersecurity teams often call this aggregation risk: information becomes more sensitive when multiple pieces are combined.\nAI makes putting all those puzzle pieces together look effortless.\nIt can take dozens of individually ordinary pieces of information and turn them into a consistent explanation, recommendation, analysis, or plan.\nAgain, the AI doesn’t need to be plotting anything nefarious.\nIt simply needs access.\nThere’s also the issue of scale—because AI doesn’t do anything halfway.\nIf a human employee accidentally sends the wrong document to a single customer, the incident might affect one person or one organization. If an AI customer-support agent has a flawed retrieval configuration, it could expose the same tAutomation is great at making things consistent—sometimes a little too consistent. thousands of times before anyone recognizes what is happening.\nAutomation magnifies consistency.\nThat is fantastic when the procedure is accurate.\nIt’s a lot less fantastic when the process is wrong, and now you’ve got a thousand identical mistakes instead of just one.\nHumans are gloriously inefficient, and sometimes that’s a good thing. We get tired, we second-guess ourselves, we ask questions, we get distracted, and yes, we go to lunch.\nAI, on the other hand, never needs a sandwich break.\nGive an AI agent permission to perform a bad action automatically, and it may execute it with admirable speed, consistency, and reliability.\nThe same problem exists with internal decision-making.\nImagine an HR assistant with access to employee information, designed to help managers answer routine policy questions. Someone asks a question that causes the AI to infer something sensitive about another employee.\nThe information may technically be available to the system, but that does not mean it should be returned.\nHumans possess social and organizational context that can be extremely difficult to encode. We often recognize when a question feels inappropriate. We notice when someone appears to be fishing for information. We understand that a technically available answer may still be something we should not disclose.\nAI can estimate those judgments.\nBut getting close isn’t the same as having that gut feeling that tells you, ‘Maybe I shouldn’t answer this question.’ That is why AI insider risk cannot be managed entirely through acceptable-use policies written for employees.\nThe AI itself needs enforceable boundaries.\nOrganizations also need to think carefully about who the “insider” actually is in an AI-enabled environment. Sometimes the insider is the AI identity. Sometimes it is the human operating through the AI. Often, it is a combination of both.\nAn employee might not have direct access to a sensitive system, but an AI agent they can invoke might. Conversely, the employee may already have broad access, and the AI makes searching and exploiting that access dramatically easier.\nThat distinction matters because AI reduces the effort required to find information.\nA person who would never manually browse through 20,000 documents might happily type, “Find anything related to executive compensation.”\nThe AI handles the hard part.\nThat means authorization has to survive the entire chain.\nJust because an AI identity can reach a repository doesn\u0026rsquo;t mean every employee interacting with that AI should receive information from it.\nThis is where identity-aware retrieval becomes critical.\nThe AI should respect the requesting user\u0026rsquo;s permissions, the permissions assigned to the agent itself, and, ideally, the authorization requirements for the specific task being performed.\nThe effective boundary should be the intersection of those permissions, not whichever permission set happens to be broadest.\nSounds complicated, right?\nSo did Zero Trust when people first started explaining it at conferences.\nEventually, it just becomes part of how we build things.\nMonitoring has to evolve as well.\nTraditional insider-risk programs look for unusual activity: large downloads, strange login locations, unexpected access to sensitive repositories, unusual file transfers, or sudden behavior changes.\nAI identities need behavioral monitoring too.\nHow many documents does this agent normally retrieve for a request? Which repositories does it usually access? What actions does it commonly perform? What does normal behavior look like for this specific AI role?\nIf a Finance AI suddenly begins querying vulnerability-management data, that should be interesting.\nIf a customer-support AI suddenly retrieves thousands of internal documents for one request, that should be interesting.\nIf an AI agent begins performing actions at a volume dramatically above its normal pattern, that should be interesting.\nThe complication is that high-volume activity may be perfectly normal for AI.\nA human reading 10,000 files in five minutes would look suspicious.\nFor an AI, reading 10,000 files in five minutes is just a typical day.\nThat means behavioral monitoring cannot rely entirely on thresholds created for humans.\nWe need to establish what normal looks like for the AI identity itself.\nData leakage also takes on a different form when AI is involved because the output may transform sensitive information rather than copying the source.\nTraditional DLP controls are good at identifying known patterns: a document, a credit-card number, a Social Security number, or another recognizable sensitive element leaving the organization.\nAI can summarize.\nIt can paraphrase.\nIt can combine information.\nIt can retrieve data from several sources and generate a completely new response that contains the same sensitive meaning without replicating the initial content.\nTraditional controls are still valuable, but they may need supplementary context.\nOrganizations will increasingly need to understand not only what data moved, but what information the AI derived from that data.\nThat’s a much tougher problem to solve.\nIt is also why logging, identity, ownership, access controls, role definitions, and monitoring all need to work together.\nNo single control is going to solve AI insider risk.\nThere is another angle worth considering: the AI itself may be manipulated by an insider.\nAn authorized employee can intentionally construct prompts designed to extract information, bypass restrictions, or convince an agent to perform actions outside its expected workflow. Prompt injection and similar attacks get plenty of attention when external adversaries are involved, but insiders can use the same techniques.\nCuriosity is a powerful adversary.\nGive employees access to a new AI system and eventually someone will type a question beginning with, “Hypothetically…”\nThat does not necessarily make them malicious.\nPeople explore. They challenge boundaries. They want to know what a system can do and what it knows.\nSecurity should assume that will happen.\nThe solution cannot depend on every user following instructions perfectly.\nThe system itself needs enforceable boundaries.\nThat is another lesson cybersecurity already learned from human identities. Policies matter, but policies work much better when the technology reinforces them.\nWe do not protect payroll by putting a sign on the system saying, “Now, all this might make AI sound like the boogeyman of insider threats. seriousness.\nAll of this may make AI sound like a terrifying insider threat.\nThat is not the point.\nThe real point is that AI takes the insider risks we already know and turns the volume up to eleven. It can access more information, process it faster, connect the dots better, remember everything, and do it all with the consistency of a Swiss watch.\nThose capabilities are incredibly valuable.\nThey are also powerful.\nThe answer is not fear.\nIt’s all about good governance—setting the rules and making sure everyone, including your AI, plays by them.\nGive the AI a unique identity. Define its job. Limit its access. Restrict its actions. Monitor its behavior. Preserve the relationship between the human request and the AI action. Detect unusual access patterns. Apply data controls to both inputs and outputs. Review permissions over time.\nMost importantly, let’s stop pretending that \u0026rsquo;not malicious\u0026rsquo; equals \u0026rsquo;not risky.'\nEmployees do not need malicious intent to expose sensitive information. The biggest insider threat you might create isn’t a grumpy admin with a mysterious USB stick. It could be your perfectly well-behaved AI assistant, happily doing exactly what it was told—with access to everything. Operating exactly as designed.\nAnd that’s exactly why AI needs a seat at the table in your next security conversation.\nZero Trust.\nBecause if AI is an identity, then the same principle we have spent years applying to users, devices, applications, and workloads applies here too.\nNever trust automatically.\nVerify continuously.\nThat is where we go next.\n","date":"25 October 2026","externalUrl":null,"permalink":"/posts/ai-is-the-largest-insider-threat-youve-ever-created/","section":"Archives","summary":"","title":"AI Is the Largest Insider Threat You’ve Ever Created","type":"posts"},{"content":"Walk into just about any company, and you’ll see that every employee has some kind of identity. Maybe it’s a badge clipped to a belt, a username in Entra ID or Active Directory, an employee number in HR, or a handful of credentials that prove, yes, this person is who they say they are.\nA physical badge might open doors. A digital identity? That’s your ticket to apps, files, databases, email, and a whole universe of cloud services. But really, both serve the same purpose: organizations need to know who’s asking for access.\nAI needs the same thing.\nIn my last post, I talked about the idea of giving AI performance reviews. Of course, that only works if we can answer a deceptively simple question: Which AI actually did the work?\nIf the answer is “the AI,” we have a problem.\nPicture trying to run a performance review for a department where every single person is named “Employee.” The logs say Employee opened a sensitive file, Employee created a ticket, Employee changed a customer record, and Employee sent an email. If you’re management, you’d want a lot more detail than that.\nBut organizations sometimes deploy a bunch of AI agents using one shared service account, API credential, or application identity—and then assume those logs are enough for real accountability.\nThey’re not.\nAI needs a badge number.\nI don’t mean a literal badge—though it’s kind of hilarious to picture a rack of badges labeled “Finance AI,” “Security AI,” and “That One Marketing Keeps Experimenting With.” What I mean is every meaningful AI worker should have a unique, managed identity that the organization can authenticate, authorize, monitor, review, and, if needed, revoke.\nThat might sound like a technical detail, but it’s actually one of the foundations of real AI governance.\nIdentity answers the first question in almost every access decision: Who are you?\nFor humans, we’ve spent decades coming up with better and better ways to answer that question. Passwords turned into multifactor authentication, then came certificates, device trust, biometrics, conditional access, passkeys, and risk-based authentication—each one adding another layer of confidence that the person (or thing) asking for access is legit.\nMachines have identities too. Applications use service principals. Workloads use managed identities. Services use certificates or keys. Automation uses tokens. APIs use OAuth and scopes.\nAI fits naturally into this world.\nThe mistake would be treating AI as somehow outside it.\nIf an AI agent can retrieve sensitive data, create records, send communications, or execute actions, it should not exist as an anonymous feature hidden inside a platform. It should have an identity that represents the role it performs.\nSuppose an organization has three AI agents. One triages security alerts. One assists Finance with invoice analysis. One helps HR answer policy questions.\nThose agents should not share the same identity.\nThe security agent needs access to security systems. Finance needs financial data. HR may need employee-policy information. If all three agents authenticate using the same service account, least privilege becomes nearly impossible. Either the shared identity receives the combined permissions of all three roles, or the organization creates increasingly complicated logic elsewhere to compensate for the fact that the identity model is wrong.\nThis is how service accounts become terrifying.\nThey start off with one clear purpose. Then another team needs them. Then a project adds a permission. A few years down the line, no one remembers who originally owned it. Suddenly, there’s an account named something like svc_prod_app01 with access to half the company—and a password last changed in a presidential administration nobody wants to talk about.\nWe do not need to repeat that history with AI.\nA unique AI identity makes authorization cleaner. The Finance assistant receives Finance permissions. The Security assistant receives Security permissions. The HR assistant receives HR permissions. If one role needs additional access, that change applies to the specific identity rather than expanding a shared credential used by unrelated systems.\nThat also improves monitoring. If the Security AI suddenly begins querying payroll information, the behavior is clearly unusual. If everything operates through a shared “AI Service” identity, the same event may be much harder to interpret.\nIdentity provides context, and that context becomes essential as AI actions become more autonomous.\nAuthentication is part of the picture, but authentication alone does not solve the problem. Knowing which identity is requesting access is useful. We also need confidence that the identity is being used legitimately.\nFor humans, this is where controls like MFA, conditional access, device trust, and privileged access management come into play. For AI and machine identities, the equivalent controls may include certificates, workload identities, managed identities, short-lived tokens, vault-managed secrets, signed requests, and restricted API scopes.\nThe implementation will vary by platform, but the principle stays the same: credentials should be strong, protected, rotated where appropriate, and limited to the intended use.\nScattering hard-coded API keys through scripts isn’t a real identity strategy. Neither is leaving a production AI token in a file called keys.txt on someone’s desktop.\nI mean, I\u0026rsquo;m sure nobody reading this has ever seen anything like that.\nDefinitely not lurking in a folder called Old.\nAI identities also need lifecycle management. Human identities have a beginning and an end. An employee joins, receives an account, changes roles, receives different permissions, and eventually leaves. Mature identity systems try to follow that lifecycle.\nAI should too.\nWhen an agent is created, its identity should have an owner and a documented purpose. When the agent changes roles, its permissions should be reviewed. When the agent is retired, the identity should be disabled and its credentials revoked.\nThis all sounds straightforward on paper, but machine identities have always been tough to manage—mostly because they don’t walk into HR and hand in their resignation.\nThey just… stick around.\nAn AI proof of concept can disappear from everyone’s calendar while its token continues to work for years.\nThat’s how digital ghosts are born.\nAI identities should therefore appear in access reviews just like other privileged or non-human accounts. Someone should periodically ask whether the identity is still needed, whether the permissions remain appropriate, whether the owner is still correct, and whether the credentials are being managed properly.\nIf nobody knows what an AI identity does, the answer shouldn’t be “leave it alone in case something breaks.”\nThat’s not governance.\nThat’s superstition.\nLogging and traceability are where the badge-number concept becomes even more important.\nSuppose a user asks an AI agent to update a customer record. Ideally, the logs should preserve several pieces of context. We should know which human initiated the request, which AI identity performed the action, what system was accessed, what change was made, and whether human approval was required.\nThat creates a chain of accountability.\nWithout it, the logs may simply show that the human user made the change even though the AI actually executed it. Or they may show that a service account performed the change without revealing which human initiated the request.\nBoth are incomplete.\nThe human and the AI are separate actors.\nWe should log them that way.\nThis distinction will become especially important when one AI can call another AI. That sounds futuristic until you look at agentic platforms today. A user may interact with one orchestrating agent that delegates a task to a research agent, which invokes another tool, which calls an automation, which changes a record.\nAt that point, “Who did this?” turns into a full-on adventure.\nIdentity has to survive the chain.\nThe organization should be able to trace the initiating user, the AI agents involved, the systems accessed, and the resulting actions. Otherwise, an incident investigation could end up looking like a corporate version of the children’s game where everyone points at someone else.\n“It wasn’t me. The orchestration agent asked the finance agent, who called the workflow, which used the service principal.”\nPerfect.\nWe’ve invented distributed accountability.\nA strong identity architecture prevents that.\nThere is also a privileged-access question. Some AI workers will inevitably require sensitive permissions. A security agent may need to query privileged systems. An infrastructure agent may eventually be able to restart services or modify configurations. A database agent may have access to sensitive records.\nThose AI identities should be treated as privileged identities.\nThat means stronger controls, more restrictive permissions, more detailed monitoring, shorter credential lifetimes, and potentially approval before certain privileges become active.\nWe already know how to protect privileged human accounts. Administrators should not use domain-admin credentials to browse the internet, read email, and sign up for the office fantasy-football league.\nThe same logic applies to AI.\nAn agent with powerful production permissions should not use the same identity for routine low-risk activities. Separating AI identities by function and privilege makes compromise, misuse, and simple mistakes easier to contain.\nIdentity also helps with attribution during failures. In the previous article, I argued that AI should receive performance reviews. If an AI makes an incorrect recommendation, causes an incident, or produces unusually good results, we need to know which system actually produced the outcome.\n“AI generated this” is about as helpful as saying, “a computer did it.”\nWhich AI? Which version? Which configuration? Which identity? Which knowledge source? Which permissions? Which human initiated the interaction?\nThe more organizations rely on AI, the more those questions matter.\nThere is another benefit to assigning AI identities: it makes AI visible.\nOne of the risks organizations face is shadow AI. Employees and departments may experiment with AI services, build agents, create API integrations, or connect data without a central inventory.\nIf AI identities are formally registered, governed, and monitored, the organization begins to develop a picture of its AI workforce.\nHow many AI identities exist? Who owns them? Which departments use them? What systems can they access? Which are privileged? Which are inactive? Which ones were created for a pilot nobody remembers?\nThat inventory will eventually become as important as inventories of human users, service accounts, applications, and devices.\nYou can’t govern identities you don’t even know exist.\nA badge number makes the worker visible.\nOf course, giving AI a unique identity does not magically solve AI security. An employee badge does not prevent an employee from doing something foolish. A username does not prevent data leakage. Identity is the foundation on which authorization, monitoring, lifecycle management, and accountability are built.\nBut without that foundation, everything else just gets harder.\nLeast privilege becomes harder because permissions are shared. Monitoring becomes harder because actions are ambiguous. Performance reviews become harder because outcomes cannot be attributed. Offboarding becomes harder because nobody knows which credential belongs to which system. Incident response becomes harder because investigators cannot determine who or what acted.\nA unique identity does not solve every problem.\nIt makes the problems solvable.\nThat’s why every meaningful AI worker needs a badge number. Give it an identity that matches its job. Protect its credentials. Limit its permissions. Log its activity. Connect its actions back to the human or process that started them. Review its access. Shut it down when the job ends.\nThose are not new ideas.\nWe already do this for every other identity that matters.\nAI just gives us a new reason to get them right.\nAnd once every AI has a badge number, there’s another question you can’t avoid:\nSo, what can that badge actually see?\nBecause AI may not be malicious, but an identity that can read faster than any employee, remember more than any employee, correlate information across departments, and operate around the clock creates a very different kind of insider risk.\nThat is where we go next\n","date":"18 October 2026","externalUrl":null,"permalink":"/posts/ai-has-a-badge-number/","section":"Archives","summary":"","title":"AI Has a Badge Number","type":"posts"},{"content":"If AI wants to hang out in the break room with the rest of us, it’s only fair that it faces the time-honored ritual of corporate life: the dreaded performance review.\nI know, it’s a bit of a letdown. We dreamed up artificial intelligence to free us from the drudgery of repetitive work, make smarter decisions, and maybe even give us a shot at escaping endless status meetings. Yet, despite all that progress, we’ve managed to drag the annual performance review right along with us into the future. Some traditions are just too stubborn to die.\nIn earlier posts, I made the case that AI deserves the full employee treatment: give it a job title, a spot on the org chart, the right access, and yes, even a manager to keep it in line. Once you’ve done all that, you’re left with the classic question every manager eventually asks: Is this thing actually any good at its job, or is it just really good at looking busy?\nThat question is more important than it sounds. AI projects usually kick off with a lot of excitement and a few jaw-dropping demos. Someone shows off a model that can summarize a 50-page report in seconds, write an email that actually sounds human, or dig up answers from the company archives faster than you can say \u0026lsquo;search function.\u0026rsquo; Everyone is impressed, pilots are launched, licenses are bought, a steering committee springs into existence, and before you know it, there’s a shiny new dashboard to admire.\nBut eventually, someone has to ask the awkward question: Is this AI actually delivering real, measurable value? Not just whether people enjoy playing with it, or if the demo wowed the crowd, or if leadership can brag about being \u0026lsquo;AI-enabled\u0026rsquo; at the next conference. The real question is whether the AI is actually doing the job it was hired for, or if it’s just another shiny object in the tech toolbox.\nThat, my friends, is what we in the business call a performance-management problem.\nFor human employees, performance conversations usually begin with expectations. What is this person responsible for? What does good performance look like? What outcomes should they produce? If an employee is hired as a security analyst, we do not measure success by how many PowerPoint slides they create unless something has gone terribly wrong with the job description.\nWe should evaluate AI the same way. If an AI is assigned to triage security alerts, measure its performance against security-triage outcomes. Does it reduce the amount of time analysts spend reviewing low-value alerts? Does it identify pertinent context accurately? Does it escalate the right events? Does it miss important events? How often does a human analyst have to correct its conclusions?\nIf the AI is a customer-support assistant, the questions are different. Does it reduce response time? Are its answers accurate? Does it resolve routine requests without creating additional work? Does it know when to escalate to a person? Are customers more satisfied, less satisfied, or confused in a new and technologically advanced way?\nThe job itself should decide which yardstick we use to measure success.\nThat might sound obvious, but it’s easy to forget when you’re dealing with AI, especially the kind that spits out polished, professional-looking results. A well-written paragraph feels valuable, a slick summary seems smart, and a tidy answer with bullet items inspires confidence. But here’s the catch: just because something looks good doesn’t mean it’s actually doing the job right. Formatting is not the same as performance—no matter how many bullet points you use.\nAn AI can crank out a beautifully written answer that’s completely wrong. It might save you ten minutes drafting a report, only to cost you an hour double-checking every sentence. It can close support tickets at lightning speed, but if half of them have to be reopened, that’s not exactly a win. Sometimes, it just shifts the work from one team to another, like a digital game of hot potato.\nIf we focus on the wrong metrics, AI can look like a superstar while quietly making the organization less efficient. To be fair, humans have been gaming the numbers for years, so at least AI is joining a well-established tradition.\nThe first category I would measure is accuracy. How often is the AI correct when correctness can be objectively determined? That may mean comparing AI recommendations to analyst decisions, checking extracted contract language against the source, validating generated code, or reviewing whether customer answers match approved policy.\nAccuracy alone is not enough, though. An AI that is 95 percent accurate sounds impressive until you learn that the remaining 5 percent involves payroll, safety systems, regulatory filings, or disabling customer accounts. Risk changes the permissible error rate.\nThe second measure should be correction rate. How often does a human have to modify what the AI produced before it can be used? This is one of the most useful measures because it exposes hidden work. Imagine an AI drafts 100 customer responses and employees have to rewrite 60 of them significantly. Technically, the AI generated 100 responses. A dashboard may celebrate that fact. Operationally, we may have built a very sophisticated first-draft machine that creates more review work than expected.\nThat might still be useful, but we should be clear about what value we’re actually getting for our investment.\nTime saved is another obvious metric, but let’s be honest about it. If an AI chops a forty-minute task down to ten, that’s a real win. If it gets the task done in five minutes but you spend twenty minutes checking its work, the improvement is a little less impressive—though the marketing team might still try to spin it as a breakthrough.\nIt’s also worth remembering that there’s a big difference between making one person more productive and making the whole organization more productive. AI might save time for one employee, but if it creates extra work for someone else, we’re just moving the bottleneck around. For example, a developer might crank out code faster with AI’s help, but if the security team has to spend twice as long reviewing it for bugs, we haven’t really moved forward. Similarly, a support AI might shorten calls, but if it just means more escalations for another team, the net gain could be zero.\nSo, when we measure performance, we need to look at the whole process—not just the part where the AI swoops in and looks impressive.\nCost should be part of the review too. AI isn’t free, even if the chat window looks friendly and inviting. There are license fees, API charges, infrastructure bills, data processing costs, integration headaches, monitoring, support, security controls, and let’s not forget the time your team spends double-checking what the AI spits out.\nSometimes, the math is simple: the AI saves 1,000 hours of staff time and costs less than the people it replaces. Easy win. Other times, the AI saves 1,000 hours but eats up several hundred hours in review, racks up a hefty infrastructure bill, and brings in a parade of consultants who say \u0026lsquo;AI transformation journey\u0026rsquo; so often you start to wonder if the buzzword is charging you.\nThat kind of math deserves a closer look before we start handing out trophies.\nSecurity performance belongs in the evaluation too. If we are treating AI as an identity, then a good performance review should include whether that identity stayed within its assigned role. Did the AI attempt to access data it did not need? Did it retrieve sensitive information unnecessarily? Did it trigger actions outside its scope? Did users find ways to manipulate it into performing unauthorized tasks? Did it create new data exposures?\nAn AI that saves everyone twenty minutes a day but constantly breaks data-handling rules isn’t a star performer. It’s basically the digital version of that employee who crushes their sales targets but can’t stop clicking on phishing emails.\nResults matter. How those results are achieved also matters.\nPerformance reviews should also look at how the AI handles escalation. I’ve said before that AI should be allowed to admit when it doesn’t know something and should know when to call in a human. If every request ends with \u0026lsquo;Please contact an administrator,\u0026rsquo; congratulations, you’ve built a very pricey FAQ page. On the flip side, if the AI never escalates anything—even when it’s clearly out of its depth—that’s a different kind of headache.\nThe goal isn’t to eliminate escalation entirely. The goal is to make sure the AI knows when to ask for help—just like any good employee.\nA good employee knows when to handle something solo and when to call for backup. AI should be able to do the same.\nThere’s another performance measure that can be a little awkward: adoption. If nobody is using the AI, that tells you something. Maybe the training was confusing, maybe people don’t know what the AI is supposed to do, maybe the interface is a pain, or maybe—just maybe—the AI isn’t actually solving a real problem.\nOrganizations should resist the urge to blame users right away. If people keep going back to the old way instead of using the shiny new AI, it’s worth asking why. Maybe the old process is just faster. Maybe people don’t trust the AI’s answers. Maybe checking the AI’s work takes too long. Or maybe the AI was built to solve the problem leadership thought existed, not the one employees actually deal with every day.\nEvery manager has met that employee who looks perfect on paper but just doesn’t quite deliver in real life. AI can have the same issue—though it usually comes with much better branding and a slicker logo.\nPerformance reviews also create a mechanism for changing authority. If an AI consistently performs well, it may be reasonable to expand its responsibilities. Perhaps an AI that initially only recommends actions can be allowed to prepare them. Later, it may be trusted to execute a narrow category of low-risk actions automatically.\nThat’s basically the AI version of getting a promotion—minus the awkward cake in the break room.\nBut promotions should be earned. Just because the technology can do more doesn’t mean it should be given more responsibility. \u0026lsquo;The new version supports autonomous workflows\u0026rsquo; might sound impressive in a product demo, but it’s not a reason to hand over the keys to the kingdom.\nThe reverse is true as well: AI can be demoted. If its accuracy drops, you can dial back its permissions. If a model update makes it act strangely, you can take away its autonomy until things are sorted out. If it starts making questionable decisions, it can go from acting on its own to just making recommendations while you figure out what went wrong.\nThere’s no shame in that. We do it with technology all the time—we just dress it up with phrases like \u0026rsquo;temporarily restricting functionality\u0026rsquo; because \u0026lsquo;we demoted the chatbot\u0026rsquo; doesn’t look great in a change-management ticket.\nPerformance reviews also force organizations to confront who is responsible for measuring results. The vendor should not be the only source of performance information. A product dashboard showing millions of AI interactions may be accurate and still tell you very little about whether those interactions created value.\nThe organization needs its own measures tied to its own goals. That means the business owner, technical owner, security team, and sometimes risk or compliance functions may all contribute to the evaluation. The business measures the outcome. Technology measures reliability. Security measures behavior and control effectiveness. Risk functions consider whether the remaining risk is acceptable.\nTogether, those measures answer a much more useful question than “How many prompts did we send last month?” They answer, “Is this AI doing the job we hired it to do?”\nEventually, organizations might even roll out official scorecards for their AI \u0026rsquo;employees.\u0026rsquo; I can already picture the spreadsheet: Accuracy, 94 percent. Time savings, 27 percent. Escalation quality, good. Security exceptions, two. Cost per transaction, trending down. Ability to complete mandatory cybersecurity training: still outperforming a few humans I know.\nWho knows, maybe we’ll even ask AI to fill out a self-evaluation form one day.\n“I believe I exceeded expectations this year by generating 4,200 reports, decreasing average response time by 37 percent, and only hallucinating an acquisition twice.”\nAt the very least, annual reviews might finally get a little more entertaining.\nJokes aside, performance management is a serious part of AI governance. Trust in AI should be earned, not handed out just because it’s shiny, the vendor is big, or the executives are excited. We should trust AI only as much as its actual performance deserves.\nThat means tracking outcomes, mistakes, costs, security behavior, escalation, and how often humans have to step in. It means checking if the AI is actually doing the job it was hired for. If it’s performing well, give it more responsibility. If not, scale it back—just like you would with any employee.\nThat’s exactly how mature organizations manage their people—and now, their digital coworkers too.\nThere’s one catch, though: performance reviews only work if you know which worker actually did the work. If ten AI agents are sharing the same login, or if everything just gets logged as \u0026lsquo;automation,\u0026rsquo; it’s pretty tough to figure out which AI deserves a gold star—or a stern talking-to.\nBefore we can give an AI a fair review, we need to know exactly which one we’re dealing with.\nIt needs a badge number.\nAnd that is where we go next.\n","date":"11 October 2026","externalUrl":null,"permalink":"/posts/ai-performance-reviews/","section":"Archives","summary":"","title":"AI Performance Reviews","type":"posts"},{"content":"By now, our AI employee has come a long way. We handed it a job, found it a department to call home, figured out what it should and shouldn’t see, and made sure it didn’t end up as a digital intern with the keys to the kingdom. (That’s tech-speak for not letting the new guy have admin rights.)\nSo far, things are humming along nicely. Our AI hasn\u0026rsquo;t tried to take over the world or accidentally order 500 pizzas to the office, so I’d call that a win.\nWhich brings us to the awkward question nobody wants to answer: Who’s actually in charge of this thing?\nThis is where AI governance gets about as clear as a cup of day-old coffee. Organizations are great at making lists of everyone involved in an AI project: business sponsors, app teams, infrastructure folks, cybersecurity, legal, privacy, procurement, compliance, data owners, and that ever-enthusiastic vendor success manager who loves to start emails with \u0026lsquo;Just checking in!\u0026rsquo;\nThat’s a lot of cooks in the AI kitchen, and if you’ve ever seen a group project in action, you know the soup can end up a little salty.\nBut just because everyone’s invited to the party doesn’t mean anyone’s actually sticking around to clean up the mess. In tech, that usually means a lot of finger-pointing and a suspiciously empty conference room when things go sideways.\nWhen AI is treated purely as technology, responsibility tends to follow whatever piece of the platform someone manages. IT owns the application. Security owns the controls. Procurement owns the contract. Legal owns the risk review. The business owns the process. Everyone owns a piece, which works reasonably well until the AI does something unexpected.\nSuddenly, figuring out who’s responsible becomes the classic group-project scenario: lots of awkward silences, everyone avoiding eye contact, and someone quietly hoping the problem goes away.\nWho approved that connector? Who gave the AI access to those documents? Who changed the prompt? Who decided it could take that action automatically? Who reviewed the output? Who has the authority to shut it down?\nTake it from someone who’s been in more than a few incident war rooms: you don\u0026rsquo;t want to start asking those questions when alarms are blaring, and everyone’s already sweating through their shirts.\nIf AI is going to operate like a worker inside the organization, then every AI needs a manager.\nNow, I’m not suggesting we start scheduling monthly performance reviews with Copilot and ask it about its five-year plan. Although, given how fast AI is evolving, its answer might be \u0026lsquo;replacing you.\u0026rsquo;\nWhat I mean is someone needs to step up and own the AI’s job description, what it’s allowed to do, how it behaves, and what comes out the other end. Someone should be able to say, without scanning the room for a scapegoat, \u0026lsquo;This AI is ours. We’re on the hook for what it does.\u0026rsquo;\nThat ownership begins with the job.\nIf Finance deploys an AI to analyze invoices, Finance should own the business outcome. If Security deploys an AI to triage alerts, Security should own that process. If Human Resources uses an AI assistant to answer employee-policy questions, HR should own the service being delivered.\nIT may operate the platform. Cybersecurity may establish controls. Legal may evaluate contractual and regulatory concerns. Privacy may define data requirements. But none of those groups can decide whether an AI is successfully performing a Finance, HR, Legal, or Customer Support function.\nThe business owns the job.\nThe technology teams help make that job safe.\nThat difference really matters, because if we’re not careful, IT ends up owning every AI just because they know where the admin console is hiding. That’s like saying the infrastructure team owns payroll just because the payroll system happens to live on their servers. Trust me, nobody in IT wants to be responsible for your paycheck.\nNobody wants that.\nEspecially the infrastructure team.\nThings get even trickier when you look at what actually tells the AI what to do. Enter prompts. In plain English, prompts are the instructions, rules, and settings that guide the AI’s behavior. Think of them as the AI’s job description, only instead of being buried in HR paperwork, they’re written in sentences the AI can understand. These aren’t just technical toggles anymore—they’re quickly becoming real business policies, written in everyday language instead of code.\nSuppose a security AI is instructed to escalate any alert involving a privileged account automatically. Somebody made that decision. If the prompt is later changed so the AI can automatically close certain alerts, somebody has expanded its authority. If a customer-service AI is told never to approve a refund above a certain amount, somebody established that threshold.\nThose are not just prompt-engineering decisions.\nThey are governance decisions.\nSomeone needs to own them.\nThis matters because prompts are sneaky-easy to change. With traditional software, you have to jump through all sorts of hoops: development, testing, change management, reviews, and enough paperwork to make your eyes glaze over. With AI, someone can rewrite a couple of sentences, and suddenly the AI is acting like it’s got a whole new job description.\nThat is powerful.\nBefore you know it, \u0026lsquo;Who changed the prompt?\u0026rsquo; will be the new \u0026lsquo;Who messed with the firewall rule?\u0026rsquo; If you’ve ever been in IT, you know that’s never a fun question to answer.\nOrganizations should be able to answer both.\nThe same issue applies to connectors. In the previous article, I argued that a connector is really another form of permission. Connecting AI to SharePoint, Salesforce, ServiceNow, GitHub, email, or a database gives it access to something it didn\u0026rsquo;t have before.\nEvery one of those connections should therefore have an owner and a reason.\nIf the AI can access SharePoint, who approved which sites? If it can query customer information, who decided which customer data is appropriate? If it can access ServiceNow, can it only read tickets, or can it update them? If someone wants to connect it to HR records, financial data, or source code, who decides whether that is justified?\nThe answer can’t just be \u0026rsquo;the admin had the button and pressed it.\u0026rsquo; That’s like saying, \u0026rsquo;the door was unlocked, so I walked in.\u0026rsquo; Not exactly a solid business process.\nTechnical ability isn\u0026rsquo;t the same as business authorization.\nSomebody has to be the grown-up in the room who says yes, and actually means it.\nAnd just as importantly, someone has to be brave enough to say no, even when everyone else is excited about the shiny new AI toy.\nThat may be the harder job.\nThere’s always a ton of pressure to make AI do more, and do it faster. People see something shiny and immediately start dreaming up what it could do if we just fed it a little more data. It’s like giving a toddler sugar and then wondering why they’re bouncing off the walls.\n“What if we connected email?”\n“What if it could see Teams?”\n“What if it could update the ticket itself?”\n“What if it could make the change instead of just recommending it?”\nThose questions are perfectly reasonable. They are also requests for additional authority.\nGood governance shouldn’t be the place where fun ideas go to die. The goal isn’t to have someone whose only job is to rain on the AI parade. But someone should be able to ask, \u0026lsquo;Why does the AI need this?\u0026rsquo; and get a better answer than \u0026lsquo;because it would be really cool.\u0026rsquo;\n\u0026lsquo;Cool\u0026rsquo; is not a security model. I checked. It’s not in any of the frameworks.\nOwnership also matters when AI output leaves the platform and becomes part of the business. One phrase I expect organizations to hear increasingly often is, “The AI wrote it.”\nThat sentence should never eliminate accountability.\nIf an AI drafts a customer communication and the company sends it, the company owns the communication. If AI generates code that goes into production, the organization owns the code. If it creates a risk assessment, financial analysis, legal summary, or security recommendation that influences a business decision, somebody still owns the decision.\nAI can’t be the new \u0026lsquo;blame the intern\u0026rsquo; when things go sideways. Trust me, the intern already has enough on their plate.\nWe can’t blame the AI model every time something goes wrong, any more than a manager can blame Microsoft Word for a terrible memo.\nThe technology contributed.\nA human or a business process still decided to trust the result.\nThis matters even more because modern AI is fantastic at sounding confident. It can take a wild guess and make it sound like it came from a grizzled expert who’s mildly annoyed you even asked. If you’ve ever met a consultant, you know the type.\nPolish creates confidence.\nConfidence creates trust.\nThat trust needs an owner.\nSomeone has to decide when AI’s work needs a human double-check and when it’s safe just to hit \u0026lsquo;send.\u0026rsquo; The answer depends on the risk. If the AI is suggesting a snazzier title for your PowerPoint, that’s probably fine. If it’s recommending firing someone, moving money, shutting down a service, or tinkering with safety systems, that’s a whole different ballgame—and one you don’t want to play without a referee.\nNot every AI decision needs a committee, a task force, and three PowerPoint decks.\nBut just because the answer pops up fast and looks pretty doesn’t mean we should let the AI make big decisions on its own. Sometimes, speed means you get to the wrong answer faster.\nMistakes are another ownership headache. Every worker messes up sometimes, and AI will too. The real question isn’t if errors happen, but what we do when they do.\nIf an AI gives a customer incorrect information, who investigates? If it retrieves information that should not have been exposed, who owns the incident? If it makes the wrong recommendation during security triage, who determines why? If it performs an unauthorized action, who has the authority to stop it immediately?\nThe answer cannot simply be “the AI team.”\nThat’s the same problem as saying \u0026rsquo;the cloud team\u0026rsquo; or \u0026rsquo;the app team.\u0026rsquo; It points to a group, but doesn’t actually pin down who’s responsible.\nThe AI should have a business owner. The underlying platform should have a technical owner. Security controls should have control owners. Data should have data owners. The responsibilities can be distributed across the organization, but accountability cannot be invisible.\nThis will really come into play during audits. If you’ve never been through one, imagine a dentist appointment, but with more spreadsheets.\nEventually, auditors will ask uncomfortable questions about AI.\nAuditors have a special talent for asking the questions that make everyone squirm. It’s practically their superpower.\nThey will want to know who approved the AI, what information it can access, how those permissions are reviewed, who monitors its activity, who approves changes, how results are validated, and what happens when the AI’s responsibilities change.\n\u0026lsquo;Bob set it up during the pilot\u0026rsquo; is not going to cut it. Sorry, Bob.\nNeither is \u0026lsquo;We think Marketing owns it.\u0026rsquo;\nGood AI governance should make ownership easy to demonstrate. Someone should be able to explain what the AI does, why it exists, who approved it, what systems it can access, who authorized those permissions, how changes are controlled, and who is responsible for the outcome.\nThat doesn’t mean every chatbot needs a 37-page governance binder, three committees, and a ceremonial handshake from Enterprise Architecture. Let’s keep things reasonable.\nThe controls should match the risk.\nAn AI helping someone rewrite a meeting agenda probably does not need the same governance structure as an agent capable of changing production systems.\nBut when AI has meaningful access to organizational data or meaningful authority to act, ownership should not be optional.\nA manager also decides when a worker is ready for more responsibility.\nThat idea maps surprisingly well to AI.\nAn AI might begin by reading information and making recommendations. After it demonstrates reliable performance, someone may want it to create tickets, modify records, send communications, or execute certain actions automatically.\nThat is a promotion.\nThe AI is receiving more authority.\nSomeone should approve it.\nBefore expanding that authority, the owner should be able to explain why the change is necessary, what evidence shows the AI is ready, what additional risk it introduces, and what happens if the new capability fails.\nThis is important because AI privilege can grow gradually enough that nobody notices how far it has expanded.\nOne connector gets added.\nThen another.\nOne action becomes automated.\nThen another.\nNone of the individual changes feel particularly dramatic. Six months later, someone discovers that the AI created to summarize help-desk tickets can now reset accounts, update production records, send external email, and access three departments.\nCongratulations. You’ve just promoted your AI intern to Chief Operating Officer, and nobody noticed until it started making executive decisions.\nPrivilege creep does not stop being privilege creep because the identity happens to be artificial.\nSomeone needs to watch it.\nGood managers also know when to reduce responsibility. If AI performance declines, reduce its authority. If a model update causes unexpected behavior, autonomous actions may need to return to human approval. If a connector creates unexpected risk, remove it. If the system starts producing poor decisions, move it from acting back to recommending while the problem is investigated.\nAnd once an AI has a manager, there is another uncomfortable part of being an employee that it probably hoped to avoid.\nPerformance reviews.\nIf AI is going to join the workforce, we should ask whether it is any good at its job.\nThat is where we go next.\n","date":"4 October 2026","externalUrl":null,"permalink":"/posts/every-ai-needs-a-manager/","section":"Archives","summary":"","title":"Every AI Needs a Manager","type":"posts"},{"content":"By this point in the series, we have given our AI worker a job, placed it somewhere in the organization, and started treating it less like a shiny new piece of software and more like something that actually performs work. That is where the conversation gets interesting, because once people see what AI can do, someone inevitably asks the next question: “What else can we connect it to?”\nModern AI platforms make that question incredibly easy to ask. They can connect to SharePoint, email, Salesforce, ServiceNow, GitHub, financial systems, HR platforms, collaboration tools, databases, and just about anything else with an API. From a technical perspective, that is impressive. From a security perspective, it is also the moment to ask a much less exciting question: What does this AI actually need?\nFortunately, cybersecurity already has an answer. We call it the Concept of Least Privilege, and despite everything artificial intelligence may change about technology, least privilege isn\u0026rsquo;t a concept that needs reinventing. The idea remains simple: an identity should receive only the access it needs to perform its assigned role. We have applied that principle to employees, contractors, administrators, applications, and service accounts for decades. AI should not receive an exemption simply because it can summarize a 200-page document in twelve seconds.\nIn the previous post, I argued that AI needs something resembling a job description. That job description becomes especially important when we begin deciding what the AI can see and what it can do. If the AI works for Finance, it may need access to budgets, invoices, accounting data, forecasts, and approved financial reporting systems. It does not need access to employee disciplinary records. An Engineering AI may need source code, architecture documentation, development systems, and build pipelines, but it has no obvious reason to access payroll. A Marketing AI may need campaign data, customer demographics, and approved product documentation, but it does not need penetration-testing reports or incident-response notes.\nThe job should determine the access, not the fact that an integration happens to exist.\nThis sounds obvious when we talk about employees. If someone started in Marketing on Monday and immediately requested access to Finance, HR, Security, Legal, executive email, source code, and every SharePoint site in the company, most organizations would ask a few questions before approving the request. When AI makes essentially the same request through a list of connectors, however, organizations sometimes treat it very differently.\n“Connector” sounds harmless. It sounds like a feature. It sounds like something we should enable because otherwise we are not getting the full value of the product.\nFrom an identity perspective, though, a connector is access.\nConnecting an AI to SharePoint permits it to retrieve information from SharePoint. Connecting it to Salesforce, ServiceNow, GitHub, or email creates a trust relationship with those systems. The terminology may be new, but the governance problem is not.\nThe risk grows because AI can use access very differently from a human employee. A person may technically have access to 50,000 documents and never open more than a few hundred of them. An AI can search all 50,000. A person may not realize that two pieces of information become sensitive when combined. AI is specifically designed to make those connections. A human could miss an old report buried six folders deep on a disregarded SharePoint site. AI may retrieve it in seconds.\nThat capability is exactly why organizations want AI. We want systems that can search faster, discover patterns, and surface knowledge people might otherwise miss. But those same capabilities make excessive access far more consequential.\nOverpermissioning is not new. People change jobs and keep access from previous roles. Contractors receive broader permissions than necessary. Service accounts accumulate privileges because nobody is quite sure what will break if someone removes them. Applications get broad API permissions because figuring out the exact permissions required would take another meeting, and nobody wants another meeting.\nAI raises the stakes.\nAn overpermissioned employee is a risk. An overpermissioned AI can be a risk at machine speed. The uncomfortable part is that AI doesn\u0026rsquo;t need malicious intent to create a problem. It may simply be extremely efficient at using exactly the permissions we gave it.\nThat is why organizations need to separate capability from authorization. We need to distinguish between “Can the AI do this?” and “Should the AI be allowed to do this?” Those questions are not the same. A security AI may be technically capable of deactivating a compromised account after reviewing an alert, but that does not mean it should automatically have permission to do so. A finance assistant may be able to interact with an accounts-payable system, but reviewing an invoice and approving payment are very different levels of authority. A customer-support AI may be able to issue a refund, but that does not mean every support interaction should have access to that capability.\nHumans already understand the difference between “can” and “may.” Most employees can walk into the CEO’s office, sit behind the desk, and rearrange the furniture. Corporate policy generally discourages this. Capability has never automatically meant authorization, and AI does not change that principle.\nThis becomes even more important as AI moves from reading information to taking action. A substantial difference exists between an AI that recommends deactivating an account and one that actually disables it. The first produces advice. The second creates operational impact. Reading a firewall rule is different from changing it. Drafting an email is different from sending it. Reviewing a payment is different from approving it.\nLeast privilege for AI must therefore consider both the information it can consume and the actions it can perform. An AI may begin by observing approved information and producing analysis. Once the organization understands its behavior, it might be allowed to recommend actions. Later, it could prepare a change, ticket, response, or transaction for human approval. Only after sufficient testing should it be given authority to execute narrowly defined actions on its own.\nEach increase in authority increases privilege, and each should have a business reason.\nAnother challenge appears when AI operates using delegated user access. Many enterprise assistants are designed to act within the permissions of the person using them, which initially sounds reasonable. If an employee can access a document, the assistant helping that employee should be able to access it too.\nThe problem is that a user’s total available access may be much broader than what the AI needs for a particular task.\nEmployees accumulate permissions over time. They may belong to old SharePoint sites, project groups, collaboration spaces, email archives, and applications they barely remember having. They may technically be authorized to access all of it, but that does not mean every AI interaction should be able to search it all.\nA considerable difference exists between what a user can access and what the AI should access for the job at hand. If someone asks an AI to summarize a security incident, it does not need to search every file the user has ever been authorized to open. If someone asks for assistance drafting a budget proposal, the AI probably does not need to search six years of personal email. The user’s maximum permission boundary does not necessarily need to become the AI’s working boundary.\nThis is one reason organizations ought to be cautious about building the all-knowing corporate AI. The idea is attractive: one assistant that knows everything. Ask it about Finance, HR, Engineering, Security, Legal, customer information, corporate strategy, and what is being served in the cafeteria.\nFrom a user-experience perspective, that seems convenient. From an identity perspective, however, we have created an account with extraordinary visibility across the organization.\nCybersecurity has spent years trying to reduce the number of highly privileged identities in our environments. We separate administrator accounts, use privileged access management, monitor sensitive activity, and create stronger controls around identities that can touch critical systems. Creating one AI with access to everything would move us in exactly the opposite direction.\nA better approach may be multiple AI identities with particular institutional roles. A Finance AI knows Finance. A Security AI knows Security. An Engineering AI knows Engineering. A Customer Support AI knows what it needs to support customers. Each identity has a purpose, an owner, and an access boundary appropriate to its work.\nThat may be less exciting than building the digital equivalent of an all-knowing corporate oracle, but it is far easier to govern. It also lowers the chance that someone asks an innocent marketing question and receives an answer informed by a confidential legal investigation, which is generally considered a positive outcome.\nAnother AI concept deserves examination through the lens of least privilege: context. We hear constantly that greater context creates better AI responses, and technically that is often true. More relevant information can improve a model\u0026rsquo;s ability to answer questions accurately.\nBut there is a major difference between greater context and appropriate context.\nIf someone asks a Finance AI to forecast next quarter’s operating costs, it may need budget information, historical spending, current contracts, and approved forecasts. It does not need employee disciplinary records, vulnerability reports, or confidential legal strategy. Those sources would provide supplementary context, but not useful context.\nAt some point, “greater context” becomes “more data than the identity should have.”\nThat is where least privilege begins to overlap with data limitation. The goal should not be to provide AI with every piece of information the organization possesses. The goal should be to provide enough authorized information for the AI to perform its assigned task accurately.\nIn many cases, limiting the AI to authoritative, relevant data may improve its work because it reduces the outdated, contradictory, or unrelated material the system has to consider. Sometimes better security and better AI performance are not competing goals. Sometimes giving the AI less information produces a better answer.\nLeast privilege is also an ongoing process, not a one-time configuration. AI roles will change just as employee roles change. Projects begin and end. Data sources get added. Agents gain capabilities. A temporary connector used during a project may no longer be required six months later.\nUnfortunately, cybersecurity history shows that temporary permissions can easily become permanent.\nSomeone adds access for a legitimate reason. Another process becomes dependent on it. The first project ends, and nobody wants to remove the permission because nobody is entirely sure what might stop working. Five years later, an auditor asks why a service account has access to eleven systems, and everyone in the room suddenly becomes fascinated by the ceiling tiles.\nAI can easily make this worse. Organizations will create agents quickly. Those agents will receive tokens, API permissions, connectors, and repository access. People will change jobs. Projects will end. Vendors will change. Without deliberate lifecycle management, companies will eventually discover AI identities whose original purpose nobody remembers but whose permissions remain surprisingly impressive.\nWe already have enough mysterious service accounts. We do not need mysterious service accounts that can also write quarterly reports.\nThis makes periodic access reviews especially important. Someone should routinely review each AI identity and ask whether its permissions still fit its job. Does the AI still perform the same function? Does it still need each connector? Has the business process changed? Has the sensitivity of the data changed? Did something that started as a six-week proof of concept quietly become production three years ago?\nThose reviews should not belong exclusively to cybersecurity. The business owner should be involved because the business owns the job. IT can implement the architecture and security can enforce the controls, but the business should be able to explain why significant permissions exist.\nThat is why least privilege should not be viewed only as a security restriction. It is a business control. It reduces blast radius when something goes wrong. It limits accidental disclosure. It improves accountability. It makes auditing and investigations easier. With AI, it also limits what the system can retrieve, correlate, summarize, and act upon.\nArtificial intelligence may change many parts of how organizations perform work, but it does not invalidate what we have already learned about identity. If an AI has a job, give it the information it needs to do it. If it needs to take action, give it only the authority necessary for those actions. If additional access becomes necessary, expand it deliberately. If the role changes, review the permissions. If access is no longer needed, remove it.\nDo not connect everything simply because the platform makes it easy, and do not create a single AI identity with visibility into the entire organization simply because users would find it convenient.\nThe Concept of Least Privilege remains exactly what it has always been: an identity should receive the minimum access needed to perform its assigned role.\nAI does not make that principle outdated. If anything, AI makes it more important, because the real danger may not be that an AI intentionally misuses excessive permissions. The more realistic problem is that it uses every permission we gave it exactly as designed, only faster and at a scale no human employee could reasonably match.\nAnd that leaves us with another problem. Once we decide what an AI should be allowed to access, someone has to remain responsible for those decisions. Someone needs to approve the connectors, review the permissions, watch for role changes, decide when additional authority is justified, and answer questions when the AI does something unexpected.\nIn other words, every AI needs a manager.\nThat is where we go next.\n","date":"27 September 2026","externalUrl":null,"permalink":"/posts/the-principle-of-least-privilege-doesnt-change/","section":"Archives","summary":"","title":"The Principle of Least Privilege Doesn’t Change","type":"posts"},{"content":"In the last post, I argued that your next employee may not have a pulse. It may have an API token instead of a username, connectors instead of application access, prompts instead of training manuals, and guardrails instead of corporate policies. The terminology is different, but once AI starts performing actual work inside an organization, the similarities between managing AI and managing employees become difficult to ignore.\nSo let’s take that idea one step further. If AI is becoming part of the workforce, maybe it needs an HR department.\nNot literally. I am not suggesting we enroll Copilot in the dental plan, invite ChatGPT to the company picnic, or schedule a difficult conversation with an agent because it has been showing up late to the morning stand-up. What I am suggesting is that organizations already have a well-established way of thinking about workers. We define jobs, assign people to departments, establish responsibilities, create reporting relationships, train new hires, evaluate performance, expand responsibilities when someone proves capable, and eventually offboard them when the relationship ends.\nFor some reason, when AI arrives, we often forget all of that and follow a very different process. Someone sees a demo. The demo is impressive. A license is purchased. A few integrations are enabled. People begin experimenting. Someone creates an agent. Someone else creates three more agents. Six months later, nobody is entirely sure which one is the official one, but at least two of them are connected to SharePoint.\nThen we start asking what exactly these systems are supposed to do.\nThat order may need some work.\nThe way we describe AI influences the way we manage it. If someone says, “We are deploying an AI platform,” the discussion immediately becomes technical. Which model are we using? Where is it hosted? Does it integrate with Microsoft 365? Can it access ServiceNow? What is the licensing model? How many tokens can it process? Does it support single sign-on?\nThose are all legitimate questions, but they are not the first questions.\nChange the sentence slightly. Instead of saying, “We are deploying an AI platform,” say, “We are hiring a research assistant.”\nSuddenly the conversation changes. What will the research assistant research? Who will use its work? What information does it need? What information should it not see? Who reviews its conclusions? What happens when it gets something wrong? How do we know whether it is actually helping anyone?\nThose sound much more like governance questions because that is exactly what they are.\nThe technology still matters. The model matters. The architecture matters. Security controls matter. But those decisions should support the job. The job should not exist simply because we bought the technology.\nBefore an organization deploys an AI agent, it should be able to explain in plain English what that agent is supposed to do. Preferably without phrases like “leverage transformative artificial intelligence capabilities to unlock enterprise synergies.” That is not a job description. That is what happens when an executive presentation is left unattended near a thesaurus.\nA useful job description should be simple enough that someone outside the AI project can understand it. Maybe the organization wants a Security Alert Triage Assistant. Its job is to review lower-severity alerts, gather context from approved systems, summarize what happened, and recommend whether the issue should be escalated to an analyst. Maybe the company wants a Contract Review Assistant that compares specific contractual language against approved standards and flags differences for legal review. Perhaps it needs a Customer Support Assistant that answers routine questions using approved documentation and hands anything unusual to a person.\nThose are jobs.\n“Use AI to improve productivity” is not a job. Neither is “implement generative AI across the enterprise.” Those are goals, strategies, or perhaps sentences designed specifically for steering committee meetings. They do not tell us what the AI is expected to do on Tuesday morning.\nThe job description matters because nearly every governance decision that comes afterward depends on it. If we do not know what the AI’s job is, we cannot reasonably decide what data it needs, what actions it should be allowed to perform, how its performance should be measured, or who should own the results.\nHumans get hired into jobs. AI should be assigned one.\nThat also means AI should belong somewhere in the organization. Employees generally have departments, managers, cost centers, responsibilities, and some identifiable place on the organizational chart. Yes, modern corporate reporting structures sometimes resemble a subway map designed by someone experiencing a personal crisis, but at least there is usually an attempt to establish who works for whom.\nAI should have the same organizational context.\nA Finance AI should belong to Finance. A Security AI should belong to Security. A Customer Support AI should belong to Customer Support. An HR AI should belong to HR. That does not necessarily mean those departments operate the underlying technology. IT may manage the platform. Cybersecurity may define the controls. Legal and privacy may establish requirements around sensitive information. Procurement may manage the vendor relationship.\nBut somebody on the business side should be able to say, “That AI works for us.”\nThis is important because AI systems can easily become everybody’s project and nobody’s responsibility. During deployment, everyone wants to participate. There are working groups, pilot teams, innovation committees, architecture reviews, and presentations with impressive diagrams showing arrows flowing between things.\nThen something goes wrong.\nAt that point, organizational ownership can become strangely difficult to locate.\nIT says it only manages the platform. Security says it established the controls. The business says it thought IT owned the AI. The vendor says the system operated as configured. Legal asks who approved the configuration. Everyone suddenly becomes deeply interested in finding the original project charter.\nA worker needs a home.\nAI does too.\nOnce we have defined the job and established where the AI belongs, the next mistake to avoid is giving it too much authority too quickly. Most organizations do not hire an employee on Monday and give them unlimited decision-making authority by Tuesday. New hires spend time learning the environment. Their work is reviewed. Someone watches how they perform. They demonstrate competence before receiving more responsibility.\nAI should follow the same pattern.\nA new AI system might begin in an observation role. It can review approved information, analyze it, and produce a recommendation. Nothing happens automatically. A person decides whether the recommendation makes sense.\nIf the AI consistently performs well, perhaps the organization allows it to prepare work. It might create the draft ticket, write the response, prepare the change request, or assemble the information someone needs to make a decision. A human still approves the action.\nOver time, after the organization understands how the system behaves, the AI might be allowed to perform a limited set of low-risk actions independently.\nThat progression looks a lot like a probationary period.\nThe AI proves it can perform the job before we expand its authority.\nThis may sound overly cautious to people excited about autonomous agents. Autonomy is, after all, where the exciting demos live. Nobody schedules an executive presentation to demonstrate an AI carefully recommending that a human review something. The room becomes much more interested when the AI clicks the button itself.\nUnfortunately, autonomous action is also where the exciting incident reports live.\nThere is nothing wrong with giving AI authority. In many cases, that is where much of the value will eventually come from. But authority should follow evidence rather than enthusiasm. We should understand how the AI performs, where it fails, how often it is wrong, how it behaves when information is incomplete, and what happens when something unexpected occurs.\nTrust should be earned.\nThat principle is familiar because we already apply it to people.\nThe same idea applies to performance expectations. One of the stranger parts of AI adoption is how often organizations implement AI without clearly defining what good performance looks like. People use the system. Everyone is impressed that it can summarize documents. Someone produces a presentation explaining that the organization is now “AI-enabled.” Eventually, someone should probably ask whether any of this is actually helping.\nEmployees have performance expectations. AI should too.\nIf we hire a security triage assistant, success might mean reducing analyst review time while maintaining a defined level of accuracy. If we hire a customer support assistant, perhaps we expect shorter response times without increasing incorrect answers or unnecessary escalations. If we deploy a research assistant, maybe we care about the accuracy of its sources, the completeness of its summaries, and how much time it saves employees.\nDifferent AI workers should have different expectations because they have different jobs.\nThat is another reason why defining the job first matters so much. We cannot measure whether the AI is performing well if we never established what it was supposed to accomplish.\nThe metrics also need to include the negative side of performance. Did the AI save employees three hours each week, or did employees spend three hours correcting its output? Did it reduce ticket volume, or merely change the type of tickets being created? Did it improve customer response times while quietly increasing inaccurate responses? Did it reduce security analyst workload but create so many false escalations that the SOC developed a new and exciting relationship with caffeine?\nThe question should not be whether the AI is impressive.\nThe question should be whether the AI is useful.\nA beautifully written wrong answer is still wrong. A fast process that produces poor outcomes is still a poor process. An AI that appears productive while creating significant cleanup work should not receive a good performance review simply because its summaries contain excellent formatting.\nThis is especially important because generative AI can be extremely confident. Confidence and competence are not always traveling together. Most organizations already have at least one employee who has demonstrated this phenomenon. AI simply gives us the opportunity to automate it.\nIf performance is good, the AI may earn additional responsibilities. That is essentially a promotion. An assistant that initially only recommends actions might later be allowed to prepare them. After additional testing, it may be allowed to perform certain low-risk tasks automatically. Maybe its approved knowledge sources expand. Perhaps it receives access to an additional application required for a new responsibility.\nThat expansion should be deliberate.\nAn AI should not get promoted because someone found another connector in the administration console and thought it looked useful.\nEvery increase in authority should have a reason. The organization should be able to explain what changed, why additional capability is necessary, what evidence supports the decision, and what controls are in place if the AI behaves unexpectedly.\nPromotions should be earned.\nAnd, like humans, AI should also be capable of being demoted.\nThis part is important because AI governance should not assume that autonomy only moves in one direction. Models change. Prompts change. Data changes. Applications change. Integrations change. Something that performed reliably six months ago may behave differently after a major update.\nIf the AI begins producing more errors, the organization should be able to reduce its authority. Move it from acting back to recommending. Require additional human approval. Restrict a connector. Limit the data available to it. Return it to observation mode while someone figures out what changed.\nThat should not be viewed as failure.\nIt is simply management.\nTrust is not a certificate we issue once and assume remains valid forever. It should be continuously supported by evidence.\nEventually, of course, the AI employee will leave.\nA project will end. A vendor will be replaced. A better model will become available. A business process will change. A proof of concept will quietly stop being used after everyone involved changes jobs. The AI itself may disappear from daily use, but its service account, API token, and application permissions may remain behind like the digital equivalent of someone leaving the company but keeping their building badge.\nWe are already very good at creating orphaned technology.\nAI gives us the opportunity to create orphaned technology that can also send email.\nThat means offboarding has to be part of the lifecycle from the beginning. When an AI role ends, its identity should be disabled. Credentials and tokens should be revoked. Connectors should be removed. Automated workflows should be stopped. Retained data should be reviewed. Required logs should be preserved. Someone should verify that the AI can no longer interact with organizational systems.\nThe principle should be exactly the same as employee offboarding: when the job ends, the access ends.\nNone of this means HR should suddenly become responsible for managing AI infrastructure. I suspect most HR departments have enough to do without receiving tickets because a chatbot wants access to Salesforce. The point is that HR has spent decades developing a lifecycle for workers, and that lifecycle gives IT, cybersecurity, and business leaders a useful model for AI governance.\nDefine the job before the worker arrives. Decide where the worker belongs. Establish expectations. Start with supervision. Expand responsibilities as trust is earned. Measure performance. Reduce authority when necessary. Remove access when the job ends.\nThat is not particularly revolutionary.\nIn fact, that is exactly why it is useful.\nArtificial intelligence can feel like an entirely new governance problem that requires completely new controls, committees, frameworks, and terminology. Some of that will certainly be necessary. AI creates risks and capabilities we have not encountered in exactly this form before.\nBut not everything is new.\nOrganizations already understand how to manage identities that perform work. We already understand roles, accountability, supervision, lifecycle management, and access control.\nThe worker has changed.\nMany of the management principles have not.\nPerhaps the biggest shift organizations can make is therefore surprisingly simple. Stop beginning every AI conversation with, “What technology should we deploy?” Start with, “What job are we trying to fill?”\nOnce that question is answered, many of the other questions become easier. The job defines the responsibilities. The responsibilities help define the information required. The information begins to define the access. The risk helps determine the level of supervision. Performance determines whether the AI deserves additional authority. And eventually, the lifecycle tells us when that authority should end.\nMaybe AI does not literally need an HR department.\nBut it absolutely needs an HR mindset.\nBecause if we are going to treat AI as part of the workforce, we should manage it like part of the workforce.\nAnd once we have written the AI’s job description, placed it in a department, and decided what it is supposed to accomplish, we arrive at the next question.\nHow much access does that job actually require?\nThat is where we go next.\nBecause AI may be new, but the Principle of Least Privilege definitely is not.\n","date":"13 September 2026","externalUrl":null,"permalink":"/posts/ai-needs-an-hr-department/","section":"Archives","summary":"","title":"AI Needs an HR Department","type":"posts"},{"content":"Your next employee may not need a desk, a laptop, a parking space, or access to the break room. It will not complain about the office temperature, schedule a meeting that could have been an email, or mysteriously disappear five minutes before a difficult conversation. It will never request vacation, submit an expense report, or spend twenty minutes trying to remember whether its password ends with an exclamation point or a number.\nIt may, however, need access to your email, SharePoint, ticketing system, source code, customer records, financial systems, collaboration tools, and security data.\nThat should probably get everyone’s attention.\nEspecially before someone gives it access to everything because “the demo was really impressive.”\nIn the first article in this series, I argued that we need to stop thinking about artificial intelligence only as technology. If AI can read information, communicate with people, retrieve organizational knowledge, perform tasks, and increasingly take action on behalf of the business, then from a cybersecurity perspective it begins to behave much more like an identity.\nIf that is true, the next logical question is what kind of identity it most closely resembles.\nI think the answer is surprisingly simple.\nAn employee.\nNot literally, of course. Your AI does not have career goals, a 401(k), or a secret LinkedIn profile it updates after a particularly frustrating staff meeting. But when you look at how AI operates inside an organization, the similarities are hard to ignore. Employees get identities. AI gets tokens. Employees get access to applications. AI gets connectors. Employees receive training. AI receives prompts, context, and retrieval sources. Employees follow policies. AI gets guardrails. Employees have supervisors. AI needs monitoring.\nAnd both can make mistakes.\nThe terminology is different, but the underlying security problems are remarkably familiar.\nEmployees Get Usernames. AI Gets Tokens. # When a new employee joins an organization, one of the first things IT does is create an identity. The employee gets a username, email address, authentication method, and access to whatever systems are required for the job. Their actions can be logged, their permissions can be reviewed, and when they leave, their account can be disabled.\nNobody considers this particularly innovative. It is simply how identity management works.\nAI needs the same basic treatment.\nThe mechanics may look different. An AI agent might authenticate through an API token, managed identity, certificate, service account, application registration, or OAuth permission. The technical implementation matters, but the larger question matters more: What identity is performing the work?\nThat becomes especially important when AI starts taking action.\nImagine an AI assistant updates a ticket, sends a message, changes a configuration, or initiates a workflow using a developer’s personal credentials. Six months later, something goes wrong and the logs show that the developer performed the action.\nDid they?\nOr did the AI?\nOr did another employee instruct the AI to do it?\nIf answering that question requires three meetings, a forensic investigation, and someone drawing arrows on a whiteboard, we probably did not design the identity correctly.\nAn AI performing work should be independently identifiable. We should know when the human acted, when the AI acted, and ideally which human initiated the AI activity.\nAccountability starts with knowing who—or what—did something.\nEmployees Get Access. AI Gets Connectors. # After an employee receives an identity, we give them access. Their role determines which applications, files, and systems they can use.\nAt least, that is the theory.\nAI works in much the same way, except the word we tend to use is connector, which somehow makes the whole process sound much less dangerous.\nConnect it to SharePoint.\nConnect it to Teams.\nConnect it to Salesforce.\nConnect it to ServiceNow.\nConnect it to GitHub.\nConnect it to email.\nPretty soon the AI is connected to half the organization, and someone asks why we cannot connect the other half because it would produce “better context.”\nNow imagine a new employee making the same request.\n“I’ll need access to Finance, HR, Legal, Security, executive email, customer records, source code, and everything in SharePoint.”\nSomeone would probably ask what their job is.\nWhen the AI asks, we sometimes call it integration.\nFrom a security perspective, the question is exactly the same: Does this identity need this information to perform the work we expect from it?\nA connector is not merely a convenience. A connector is access.\nAnd access is permission.\nThat distinction becomes important because AI can consume information at a scale humans simply cannot. A person may have access to thousands of files and never look at most of them. AI can search through those files in seconds, correlate information across repositories, and surface relationships that a person may never have noticed.\nThat ability is one of the reasons AI is so valuable.\nIt is also one of the reasons access matters so much.\nEmployees Get Training. AI Gets Context. # New employees do not simply receive credentials and get released into the organization with instructions to “figure it out.”\nUsually.\nThey receive training. They learn company terminology, processes, policies, systems, and expectations. They learn who approves what, where information lives, and which procedures everyone claims are documented even though the only person who actually understands them is Susan from Accounting.\nAI needs organizational training too.\nWe may call it system instructions, prompts, retrieval-augmented generation, knowledge bases, embeddings, context, or reference material, but the purpose is similar. We are teaching the AI how our organization operates and giving it the information required to do its job.\nThat raises a question organizations may not enjoy answering:\nHow good is the information we are giving it?\nEvery organization has old procedures, outdated policies, abandoned project plans, contradictory documentation, and multiple files named some variation of FINAL, FINAL2, and FINAL-USE-THIS-ONE.\nHumans eventually learn which information is current and which documents everyone quietly ignores.\nAI may not.\nIf we connect an AI assistant to a decade of organizational information without identifying what is authoritative, we should not be surprised when it confidently provides the correct answer from 2019.\nThat is not necessarily an AI failure.\nIt may simply be exposing an information-governance problem we already had.\nAI does not magically fix bad information.\nSometimes it just finds it faster.\nEmployees Have Policies. AI Has Guardrails. # Employees are expected to follow rules. There are acceptable-use policies, security policies, data-handling requirements, codes of conduct, confidentiality rules, and dozens of other documents everyone promises to read before clicking the button marked “Acknowledge.”\nThe point of those policies is to establish boundaries.\nAI needs boundaries too.\nWe tend to call them guardrails, but the idea is not especially new.\nAn AI may be allowed to summarize a security incident but not close it. It may prepare a customer response but not send it. It may review a proposed firewall change without implementing it. It may analyze financial information without approving a payment.\nThe important distinction is between can and may.\nAn AI may technically be capable of doing something. That does not mean the organization has authorized it to do it.\nHumans have the same problem. Most employees are technically capable of walking into the CEO’s office and rearranging the furniture.\nCorporate policy generally discourages this.\nCapability has never been the same thing as permission.\nAI does not change that.\nEmployees Have Supervisors. AI Needs Monitoring. # We do not normally hire an employee, give them access to sensitive systems, and then never pay attention to what they do again.\nTheir manager supervises their work. Security monitors authentication and access. High-risk activities receive additional scrutiny. Privileged activity may be logged or reviewed.\nAI should not receive less oversight because it happens to run on a server.\nIn some situations, it probably needs more.\nAI can process information at machine speed. It can interact with multiple systems, retrieve enormous amounts of data, and perform a series of actions much faster than a person.\nThat means simply logging the user’s prompt is not enough.\nImagine someone asks an AI assistant:\n“Find our current remote-access policy.”\nThe prompt is useful information, but I also want to know what happened next. Did the AI retrieve the current approved policy from a known repository? Did it search three documents? Did it search 30,000 files across HR, Finance, Legal, Security, and a forgotten SharePoint site containing lunch menus from 2014?\nThe prompt tells us what the user asked.\nThe activity tells us what the AI did.\nThose are not always the same thing.\nIf AI is going to become an identity inside the environment, security teams need visibility into both.\nEmployees Make Mistakes. AI Hallucinates. # People make mistakes all the time.\nWe misread instructions. We remember things incorrectly. We use outdated information. We send email to the wrong person. We confidently answer a question in a meeting and realize halfway through the sentence that we have absolutely no idea where we are going with it.\nHumans invented hallucinations long before artificial intelligence.\nWe just did not have a technical term for it.\nThe difference with AI is scale.\nA human employee may make one bad decision.\nAn automated AI system may make the same bad decision 5,000 times before anyone notices.\nThat means AI mistakes have to be treated as operational risk. Higher-impact actions may require human review. Uncertainty needs escalation paths. Activity needs logging. Systems need boundaries.\nMost importantly, AI needs to be allowed to say, “I don’t know.”\nWe sometimes treat that response as a weakness.\nIt may actually be one of the most important controls we can build.\nThere is nothing particularly dangerous about uncertainty.\nConfidence combined with uncertainty is where things get interesting.\nEmployees Can Leak Data. So Can AI. # Organizations have spent decades trying to prevent employees from exposing sensitive information. We use access controls, data classification, DLP, security awareness training, email protections, monitoring, and countless other controls.\nThen AI arrives and someone connects it to every document the organization has produced since Windows 95.\nWhat could possibly go wrong?\nAI does not need malicious intent to expose sensitive information.\nNeither do employees.\nA user may simply ask a question without realizing the answer requires information they should not see. AI may retrieve something from an unexpected repository. It may combine information from multiple sources in a way that suddenly makes previously disconnected data sensitive.\nThat is part of what makes AI powerful.\nIt can find relationships humans miss.\nBut that capability works both ways.\nThe problem is not necessarily that AI broke the rules.\nThe AI may be using exactly the access we gave it.\nThat should make security teams uncomfortable in a productive way.\nWhen AI surfaces information it should not have, our first question should not always be, “Why did the AI show this?”\nSometimes the better question is:\nWhy could it see it in the first place?\nWe Already Know More Than We Think # The comparison between AI and employees is not perfect, and it is not supposed to be.\nAI is not human. It does not have judgment in the same sense, professional ethics, loyalty, intent, or an inexplicable desire to schedule meetings at 4:30 on Friday afternoon.\nBut from an identity and security perspective, the similarities are useful.\nAI needs to authenticate.\nIt needs access.\nIt needs organizational knowledge.\nIt needs rules.\nIts activity needs to be monitored.\nIt can make mistakes.\nIt can expose information.\nAnd someone needs to be accountable for what it does.\nNone of those problems are entirely new.\nWhat is new is the type of worker creating them.\nThat should actually be reassuring. Cybersecurity does not need to throw away everything we have learned about identity simply because AI is involved. In many cases, we need to apply those lessons more consistently.\nAnd perhaps borrow a few ideas from another department while we are at it.\nHR has spent decades figuring out how to bring new employees into an organization. Before someone starts, there is supposed to be a job. Someone approves that job. Someone becomes the manager. Expectations are set. Training happens. Performance gets evaluated. Responsibilities change. Eventually, the employee leaves.\nIT built systems around that lifecycle.\nYet with AI, organizations sometimes jump directly from “We bought Copilot” to “Let\u0026rsquo;s connect everything” without stopping to define exactly what this new digital worker is supposed to be.\nMaybe deploying AI is not really the right analogy anymore.\nMaybe we should start thinking about hiring it.\nAnd if we are going to hire AI, that raises an interesting question:\nDoes AI need an HR department?\nThat is where we are going next.\n","date":"23 August 2026","externalUrl":null,"permalink":"/posts/your-next-employee-doesnt-have-a-pulse/","section":"Archives","summary":"","title":"Your Next Employee Doesn’t Have a Pulse","type":"posts"},{"content":"This is the first post in a twelve-part series about a simple shift: organizations should treat AI not only as software, but as something that performs work. That makes AI a business conversation, not just a technology or cybersecurity one. Before AI is connected to everything, invited into every workflow, or handed the digital equivalent of a master key, it needs a role, an owner, and boundaries.\nLet’s Set the Stage\nFor this series, an identity is anything the organization can recognize and grant access to information, systems, or actions. A user is usually a person; an identity can also be an application, service account, device, API token, automation, or AI agent. That distinction matters because AI often operates through non-human identities that still need the same basic questions answered: what is it, what can it do, who owns it, and when should its access end?\nI was at a conference recently where someone framed AI in a way that stuck with me: it is not just another technology to deploy, but something organizations are beginning to “hire” to do work. I liked that framing because it moves the conversation away from tools and features and toward roles, ownership, access, and accountability.\nAI is different because it does not just sit there waiting to be used. It can read information, answer questions, draft content, summarize conversations, recommend decisions, and in some cases take action inside business systems. At that point, it starts to look less like a tool and more like a very fast new coworker who does not sleep, does not take lunch, and somehow already knows where the old project files are buried.\nDefine the Job Before Granting Access\nWhen a person joins an organization, ownership is clear. HR defines the relationship, the manager explains the job, IT provides tools, finance approves budget, legal and compliance set obligations, and the employee receives access, training, supervision, and feedback. AI should start the same way: with a clear job.\nEmployees do not receive access to everything simply because it would be convenient. A marketing employee does not automatically get payroll data, a developer does not need employee medical records, and a customer service representative should not be reading confidential merger documents between support calls. We understand those boundaries when people are involved.\nWhen an AI platform arrives, the conversation often changes to capabilities: Can it search files, read email, summarize meetings, connect to ticketing systems, or help with code? Those are reasonable questions, but they should come after the more important one: what job is this AI supposed to do?\nIf an AI has access only because a connector exists, that is not strategy. That is shopping with better branding.\nIf It Can Act, It Needs Accountability\nThe word “identity” can sound technical, but the idea is simple. If something can get into company systems, read company information, or act on behalf of the organization, we need to know what it is, what it is allowed to do, who is responsible for it, and how to stop it if something goes wrong.\nOnce AI can read data, retrieve documents, call an application, send a message, modify a record, or trigger a workflow, it deserves the same kind of accountability we expect for any other worker. It should have a defined owner (Manager), a documented purpose, limited access, monitoring, periodic review, and a clear way to turn it off (Terminate).\nAI Makes Poor Boundaries More Expensive\nPoorly defined access is not only a cybersecurity problem. It can become a legal, privacy, compliance, customer trust, and financial problem. AI makes those problems more visible because it can search, summarize, compare, and correlate information much faster than a person can.\nIt can connect financial forecasts with internal strategy documents, compare customer complaints with legal correspondence, or summarize employee information alongside management notes. The issue is not that the AI has bad intentions. The issue is that it is efficient, and efficiency without boundaries can create very expensive surprises.\nInstructions Are Not Boundaries\nA lot of AI governance focuses on instructions: what users may ask, what the AI may say, and how to prevent bad prompts or outputs. Those controls matter, but they are not enough.\nIf an AI should not be using acquisition plans, employee records, customer contracts, or sensitive financial data, the stronger control is making sure it cannot reach information its role does not require.\nEvery AI Needs a Manager and an Offboarding Plan\nEmployees have managers because someone must be accountable for their work. AI needs ownership for the same reason. Someone must know who approved it, what it is supposed to accomplish, which data it uses, who reviews its results, who responds when it makes a mistake, and who decides whether it should gain new capabilities.\nWithout a clear owner, AI becomes a shared responsibility that everyone supports and no one manages — usually right up until something breaks.\nAI systems will not remain in your environment forever. Vendors will change, projects will end, models will be replaced, and pilots will be abandoned. When an AI service is retired, its access and data connections should be retired too.\nThat means removing permissions, disconnecting data sources, disabling accounts or keys, reviewing retained information, and preserving records according to policy. In other words, offboard the AI like an employee.\nChange the Conversation\nThe next time someone proposes a new AI deployment, do not begin only with the model, the features, or whether it integrates with everything. Start with better business questions: What job is this AI being hired to do? Who owns the outcome? What information does it need — and what should it never see? What decisions or actions can it influence? How will its access be removed when the work ends?\nAI is often described as transformational technology. Inside the business, it increasingly behaves like a worker: it receives access, performs tasks, handles information, communicates with people, and sometimes acts on behalf of the organization. Once we recognize that, the path becomes clearer: define the role, assign an owner, limit access, monitor the work, review the results, and remove access when the role ends. Organizations should stop asking only how to deploy AI and start asking how to onboard it.\nIn the next post, Your Next Employee Doesn’t Have a Pulse, we will take the employee comparison more literally.\n","date":"2 August 2026","externalUrl":null,"permalink":"/posts/ai-is-an-identity-not-just-a-technology/","section":"Archives","summary":"","title":"AI Is an Identity, Not Just a Technology","type":"posts"},{"content":"Hi there! I\u0026rsquo;m a tech enthusiast, occasional wordsmith, and full-time humor aficionado with over 30 years of experience in technology (which is a nice way of saying I\u0026rsquo;ve been staring at glowing screens since they were boxy and beige).\nI am a long-time technologist with a view on how to make technology secure and yet easy to use for everyone.\nWhen I\u0026rsquo;m not juggling tech and community commitments, you can find me indulging in coffee, sarcastic commentary, and the occasional dad joke.\nWelcome to my blog—where tech meets wit, and I promise to keep the jargon to a minimum!\nCyberBunny ","date":"10 October 2025","externalUrl":null,"permalink":"/about/","section":"New England Cyber","summary":"","title":"About Me","type":"page"},{"content":"","date":"1 September 2025","externalUrl":null,"permalink":"/tags/career/","section":"Tags","summary":"","title":"Career","type":"tags"},{"content":"","date":"1 September 2025","externalUrl":null,"permalink":"/tags/job-interviews/","section":"Tags","summary":"","title":"Job-Interviews","type":"tags"},{"content":"","date":"1 September 2025","externalUrl":null,"permalink":"/tags/professional-growth/","section":"Tags","summary":"","title":"Professional-Growth","type":"tags"},{"content":"💼 _This is an updated and slightly more sarcastic version of a post I originally shared on LinkedIn back in October 2017. Over the years, I’ve been on enough interviews to confirm one thing: interviews are like dating—if the first impression is terrible, you probably shouldn’t sign a long-term contract. Given this is Labor day, I thought it was a good idea to update this post.\n🛣️ Job Interviews: A Two-Way Street (and Sometimes a Comedy Show) # Job interviews are stressful. You dress your best, rehearse your answers, and spend the car ride over giving yourself a pep talk that sounds suspiciously like you’re about to enter a boxing ring.\nAnd yet, many of us forget something important: you are also interviewing the company.\nYes, they’re judging whether you’re “worthy.” But you’re also deciding whether you want to spend 40+ hours a week with these people… potentially until one of you retires, gets promoted, or escapes to a cabin in the woods.\nI learned this lesson in the most awkward way possible.\n🎭 The Interview From the Twilight Zone # Several years ago, I went to interview for a Systems Manager role at a healthcare software company.\nIt was a classic New England downpour, but I showed up 10 minutes early. Because that’s what professionals do.\nI checked in. I waited.\nTen minutes.\nTwenty minutes.\nFinally, an HR rep rushed in, drenched from the rain, and apologized. (Apparently, water falling from the sky had completely derailed the corporate calendar.)\nWe go to a conference room. She fumbles with a folder and starts reviewing a résumé—I can see the name is NOT MINE.\nThe folder said “Systems Administrator” and had no other papers inside.\nStrike one.\nWe waited 15 more minutes for the first interviewer. He arrived with… nothing. No résumé, no notes, no clue.\nThen HR introduced me by the wrong name.\nStrike two.\nI corrected her, handed over my extra copy of my résumé (pro tip: always bring one), and the manager began the “interview” by… not asking me a single question. He just blinked at me, waiting for me to perform like a TED Talk on demand.\nAt this point, I’m thinking:\nThey don’t know who I am.\nThey don’t know why I’m here.\nI should have stayed home and made pancakes. 🥞\nThen the technical interviewer comes in. His opening line:\n“Our systems are a disaster… but there’s nothing we can do. That’s just how it is.”\nStrike three.\nI looked at the HR rep and politely said:\n“I don’t believe this company or position is the right fit for me.”\nThen I walked out, into the rain, completely drenched but spiritually free.\n🚩 What I Learned (and What You Should Watch For) # That interview taught me that interviews are not just about you proving yourself to them. They’re also a window into the company’s culture.\nIf you see these red flags, consider running—preferably before the rain starts. Keep in mind, I have had ALL of these happen to me:\n⏰ They are late – Life happens, but if a company treats the interview like it’s optional, imagine how they’ll treat your work-life balance. “Sorry you missed your kid’s birthday party… TPS reports don’t wait!”\n📄 They are unprepared – If they can’t remember who you are or why you’re there, they probably run the company with the same “winging it” philosophy.\n🕶️ They are unprofessional – I’ve been to interviews where someone showed up in a Hawaiian shirt unbuttoned to mid-chest. Unless you’re applying to be a cruise director, this is a red flag.\n📵 Phone interview no-shows – Nothing says “we value your time” like leaving you on hold staring at your own reflection for 30 minutes.\n🎤 They only ask generic questions – If the entire interview feels like they Googled “top 10 interview questions” five minutes before you arrived, that tells you how creative (or not) they are.\n🌐 Their social media tells the story – Check your interviewers on LinkedIn. If all they post are corporate press releases and nothing that shows thought leadership or industry awareness, the culture might be as stagnant as their feed.\n🌟 The Takeaway # The job hunt is stressful, but remember:\nYou are not just trying to get a job.\nYou are trying to find a place where you can thrive.\nA bad interview can actually be a gift. It’s the universe saying:\n“You just dodged a full-time headache.”\nWalk away. Dry off. And save your energy for the company that deserves you.\n","date":"1 September 2025","externalUrl":null,"permalink":"/posts/job-interview/","section":"Archives","summary":"","title":"What Job Interviews Really Reveal — And How to Spot a Bad Company","type":"posts"},{"content":"","date":"11 August 2025","externalUrl":null,"permalink":"/tags/cybersecurity/","section":"Tags","summary":"","title":"Cybersecurity","type":"tags"},{"content":"","date":"11 August 2025","externalUrl":null,"permalink":"/tags/end-of-life/","section":"Tags","summary":"","title":"End-of-Life","type":"tags"},{"content":"","date":"11 August 2025","externalUrl":null,"permalink":"/tags/log4j/","section":"Tags","summary":"","title":"Log4j","type":"tags"},{"content":"","date":"11 August 2025","externalUrl":null,"permalink":"/tags/open-source/","section":"Tags","summary":"","title":"Open-Source","type":"tags"},{"content":"🖥️ Open source was supposed to be a beacon of innovation and collaboration. Today, it’s also one of our largest unacknowledged security risks.\nBack in February 2024, I shared a post on LinkedIn about the risks I was seeing in the world of open-source software—and it resonated with a lot of people. This blog entry is an expanded update to that original post, with added thoughts and lessons learned since then.\nI might not have had “Information Security” officially in my title until recently, but I’ve always been passionate about securing the environments I support. Over the years, I’ve seen the good, the bad, and the downright terrifying. And nothing better captures that range of experience than the current state of open-source software in enterprise environments.\n🌐 What is Open Source, Really? # Open-source software is often romanticized. It’s a beautiful concept:\n“Open-source software is code that is designed to be publicly accessible—anyone can see, modify, and distribute the code as they see fit.”\n— Red Hat\nThe idea aligns perfectly with the spirit of the open web—knowledge and tools shared for the greater good.\nBut as with most great ideas, reality complicates the dream:\nCompanies take open-source code, make minor “proprietary” tweaks, and sell it as a commercial product. Others embed open-source components in their applications and fail to give credit to the original creators. And the worst offenders? They never maintain the software they’ve shipped—leaving their customers unknowingly exposed. 🚨 Log4J: The Security Wake-Up Call # The Log4J vulnerability was a seismic event in cybersecurity. But the real lesson wasn’t just about a single CVE—it was about how organizations responded.\nWhen Log4J 2.x vulnerabilities hit in 2021, I saw three types of responses:\nDenial: “We don’t think we use Log4J.” Excuses: “We can’t patch, but our Java version keeps us safe.” False confidence: “We’re using Log4J 1.x, so we’re fine.” Here’s why #3 is terrifying:\nLog4J 1.x went End-of-Life (EOL) in August 2015. EOL software receives no security patches and no official vulnerability reporting. Running it in production is like leaving your front door open with a sign that says “We trust nobody will come in.” To put that timeline into perspective:\nWindows XP and Windows Server 2003 went EOL in July 2015. Log4J 1.x went EOL just one month later. Would you run Windows XP in production today? Of course not.\nSo why is it considered acceptable to run EOL software libraries in mission-critical applications?\n🛑 End-of-Life = End of Safety # From a vulnerability management perspective, the equation is simple:\nEOL Software = Inherently Vulnerable\nIt doesn’t matter if a specific CVE isn’t attached to it. Without patches, you’re operating blind:\nVulnerabilities may exist but never be reported. Exploits can quietly circulate in the wild. Attackers know exactly which abandoned software to target. When our team scanned our environment for Log4J, the results were shocking:\nNumerous vendors shipped applications with Log4J 1.x. Some vendors refused to patch, saying 1.x wasn’t part of CVE-2021-45105. One vendor’s “fix” was to downgrade from 2.x to 1.x and release that as a patch. Think about that: a security patch that reintroduced unsupported software into production.\n🤔 The True Hypocrisy of Open Source # Here’s where the hypocrisy becomes crystal clear:\nVendors will refuse to run Windows XP or Server 2003 because they are EOL. But the same vendors ship applications built on Log4J 1.x, which has been EOL for nearly a decade. When pressed, their reasoning is always:\n“That OS is unsupported and unsafe.”\nExactly. So why does that logic not apply to the software components inside your product?\nThis double standard puts customers in a lose-lose situation:\nYou can’t patch it yourself because it’s buried in the vendor’s code. The vendor won’t fix it because “no CVE exists.” Meanwhile, attackers don’t care about excuses—they care about entry points.\n💡 Moving Forward # I ended my original post with a call for change, and I feel even more strongly today:\nVendors must own their dependencies. If you ship a product, you inherit the responsibility for every library you embed. Security teams must scan for EOL software, not just known CVEs. Customers must hold vendors accountable. If a component is EOL, demand a roadmap for removal. Open source is powerful, but freedom without responsibility creates risk. Until the industry embraces that reality, we will keep reliving the same cycle:\nVulnerability discovered. Industry scrambles. Vendors shrug and point fingers. It’s time for that cycle to break.\n","date":"11 August 2025","externalUrl":null,"permalink":"/posts/the-hypocrisy-of-open-source-an-update/","section":"Archives","summary":"","title":"The Hypocrisy of Open Source: An Update","type":"posts"},{"content":"","date":"11 August 2025","externalUrl":null,"permalink":"/tags/vendor-risk/","section":"Tags","summary":"","title":"Vendor-Risk","type":"tags"},{"content":"","date":"11 August 2025","externalUrl":null,"permalink":"/tags/vulnerability-management/","section":"Tags","summary":"","title":"Vulnerability-Management","type":"tags"},{"content":"","date":"1 August 2025","externalUrl":null,"permalink":"/tags/accountability/","section":"Tags","summary":"","title":"Accountability","type":"tags"},{"content":"","date":"1 August 2025","externalUrl":null,"permalink":"/tags/data-protection/","section":"Tags","summary":"","title":"Data-Protection","type":"tags"},{"content":"","date":"1 August 2025","externalUrl":null,"permalink":"/tags/governance/","section":"Tags","summary":"","title":"Governance","type":"tags"},{"content":"","date":"1 August 2025","externalUrl":null,"permalink":"/tags/privacy/","section":"Tags","summary":"","title":"Privacy","type":"tags"},{"content":" 🌸 Privacy is a beautiful thing # It’s why your medical records aren’t on Facebook, why you can Google “do raccoons hold grudges?” at 3 AM without shame, and why organizations like mine fight daily to keep your data safe.\nBut privacy has a dark side: it sometimes protects the wrong people.\n🕵️ Everyone Wants Privacy… Until They Want Gossip # Here’s the paradox:\nWe want to block everyone else — except us — from accessing your data.\nI once saw a senior leader (name withheld to protect the ironically privacy-obsessed) refuse to report a cybersecurity incident despite a legal obligation to do so.\nTheir reasoning?\n“We don’t want the bad press.”\nThis, even after the regulatory agency reassured us that the report would be completely anonymized — no names, no scarlet letters, no headlines reading “Organization Follows the Law Like a Responsible Adult.”\nFast-forward a few weeks. Another agency in our sector gets hit. Suddenly, the same leader comes charging in like a caffeine-fueled Columbo:\n“Who was it? Are they like us?”\nAnd I had to reply:\n“I don’t know. Their name isn’t in the report. You know… privacy.”\nThe irony could power a small city.\n🛡️ When Privacy Becomes a Shield for Bad Behavior # The original point of privacy frameworks was to protect the innocent.\nBut increasingly, they’re also used as shields for bad behavior:\nCriminals use privacy tools to launder stolen funds through crypto wallets or hide in anonymous networks. Organizations exploit privacy laws to dodge accountability for security failures. Governments invoke privacy to withhold details — right until they want to peer into your life. It’s the modern version of Swiss bank accounts. Once upon a time, they were a playground for tax evaders and thieves. Now, their replacements are encrypted servers, anonymous hosting, and cold wallets.\nEven regulatory oversight can fall into this trap. Take the U.S. FISA courts — designed to balance national security with civil liberties. In theory, they scrutinize surveillance requests. In practice? They’ve been called rubber stamps with gavels, approving the vast majority of requests with little true review.\nMeanwhile, hackers and careless insiders thrive in the shadows of “privacy.”\n🤹 The Three Great Ironies of Privacy # We demand privacy for ourselves, but transparency from everyone else.\nPeople cheer for anonymous incident reporting — right up until they want to know if their neighbor’s data got stolen. Privacy laws protect companies from embarrassment more than consumers from harm.\nEver notice how breach notifications arrive long after the bad guys already have your Social Security number? The criminals benefit the most.\nRansomware gangs love privacy. Anonymous crypto payments? They’re basically running loyalty programs. ⚖️ Privacy vs. Accountability: A Broken Equation # Here’s the hard truth:\nAbsolute privacy and absolute accountability cannot exist at the same time.\nIf every report is anonymized, we can’t learn who failed or how to prevent it. If every report is public, organizations hide incidents to protect their reputation. The solution isn’t easy, but it’s necessary:\nContextual Privacy – Protect victims, not villains.\nOrganizations that cooperate and report in good faith deserve anonymization. Those that cover up? Name and shame. Tiered Transparency – Public summaries for citizens, detailed reports for trusted sector peers.\nIn industries like transportation, knowing “how” matters as much as “who.” Cultural Courage – Stop letting “fear of bad press” dictate security decisions.\nReputation can be rebuilt. Trust can’t if you’re caught hiding the truth. 🎭 The Punchline # Privacy is a pillar of a free society.\nBut when it becomes a cloak of invisibility for bad behavior — shielding hackers, negligent executives, or governments from accountability — it stops protecting the public and starts protecting the problem.\nEveryone loves privacy…\nUntil the person you’re protecting turns out to be the villain.\nThen suddenly, everyone wants answers.\n","date":"1 August 2025","externalUrl":null,"permalink":"/posts/the-privacy-conundrum/","section":"Archives","summary":"","title":"The Privacy Conundrum: When Privacy Protects the Wrong People","type":"posts"},{"content":"First, let’s clear up what I mean by “Artificial Intelligence.”\nFor the purpose of this post, I’m using this definition:\n“AI is a form of machine learning that relies on a large base of existing information to provide a more robust ability to find, process, and suggest changes to data.”\nWhy this definition?\nBecause when people hear “AI,” they often picture what Hollywood has promised: sentient robots, decision-making machines with minds of their own, and synthetic beings pondering morality or falling in love.\nLet’s dial that back.\nWhile today’s AI systems do make decisions, those decisions are rooted entirely in learned data. The AI doesn’t dream. It doesn’t ponder the unknown. It can’t come up with a new idea just because it feels like it. There’s no abstract thought. No spark of creativity born from lived experience.\n📚 Imagine This: # Picture a brilliant librarian who has read every book ever written. You can ask them anything—from how to cook lasagna to how string theory works—and they’ll give you a well-structured, surprisingly insightful answer.\nBut here’s the twist:\nThis librarian can’t think the way humans do. They can only remix what they’ve read. They don’t have curiosity, opinions, emotions, or goals. Ask, “What should I do with my life?” and they’ll give you a handful of options based on others’ writings—but no personal insight. No lived truth. No gut feeling.\nThat’s today’s AI.\nIt’s a pattern recognition machine.\nExtremely good at predicting what answer should come next based on mountains of training data—but it doesn’t understand any of it the way you and I do. It reflects knowledge. It doesn’t possess it.\n🚧 So What Does This Mean for Work? # Any major technological leap in the past century has come with a familiar fear:\n“This will replace workers.”\nWe heard it with the rise of factory automation, computers, the internet, and even Microsoft Excel.\nAnd in truth? Some jobs were replaced. But more often, workers evolved. Roles shifted. New jobs emerged. Skills became differentiators. The workforce didn’t disappear—it adapted.\nAI is no different.\nJust like with the rise of the personal computer, we’re seeing a divide:\nThose who learn to work with the new tool, and those who don’t.\nThink back to the early days of computers. Some workers learned to navigate spreadsheets, word processors, and databases. Others didn’t—and found themselves left behind. Even today, the ability to perform a smart Google search is a legitimate technical skill.\nThe same will apply with AI:\nNot “Can AI take your job?” but _“Can you use AI to do your job better, faster, or more creatively?”\nSo What Can You Do? Start Building These Skills Now # The key question isn’t “Will AI take my job?”\nIt’s “How can I use AI to become better at my job—or pivot into a new one?”\nHere are five critical skills that will help workers stay ahead as AI becomes more integrated into the workplace:\n1. Prompt Engineering (a.k.a. Talking to AI Well) # Interacting effectively with AI is a new literacy.\nKnowing how to structure prompts—what to ask, how to ask it, and how to refine the results—is already becoming a core skill. The better your prompts, the better the output.\nThink of it like giving instructions to a very smart intern: vague direction leads to vague results.\n🛠 Try this: Practice giving clear, concise prompts to tools like ChatGPT, Gemini, or Claude. Learn how to iterate and refine your questions.\n2. Critical Thinking and Judgment # AI can give you information, but it can\u0026rsquo;t tell you if it\u0026rsquo;s right or relevant.\nThat’s where human judgment comes in. You’ll need to evaluate what AI gives you—fact-check it, weigh context, and make informed decisions.\nThe future belongs to the editors, not the generators.\n🛠 Try this: Ask an AI to summarize a topic you know well. Compare its output to reality. Spot errors. Get good at being the quality control.\n3. Data Literacy # Whether you’re in marketing, HR, logistics, or finance—understanding how data works (and how AI uses it) will give you a major edge.\nYou don’t need to be a data scientist. But you should be able to interpret charts, understand basic data structures, and question sources.\n🛠 Try this: Learn some basics of Excel, SQL, or Google Sheets. Play around with pivot tables. Take a free data literacy course.\n4. Tool Integration and Workflow Automation # AI works best when integrated into real processes. That means learning how to connect AI tools with the apps you already use—email, documents, spreadsheets, task managers, customer support platforms, and more.\nWorkers who know how to automate boring tasks with AI? Game-changers.\n🛠 Try this: Explore tools like Zapier, Make.com, Notion AI, or Microsoft’s Copilot. See where you can automate your daily workflows.\n5. Communication and Storytelling # AI can help generate content, but the ability to craft compelling narratives and communicate with clarity is still uniquely human. Explaining ideas, persuading stakeholders, and telling stories that stick will remain irreplaceable skills.\n🛠 Try this: Take time to improve your writing and presentation skills. Use AI to help brainstorm—but make the final voice yours.\n🚀 Final Thoughts # AI is a force multiplier. It’s not the end of work—it’s the beginning of a new way to work.\nJust like workers who embraced computers in the 80s or the internet in the 90s, the people who thrive in this new era will be those who learn, adapt, and grow alongside the technology.\nAnd in the spirit of transparency—yes, I used AI to help me write this post.\nBut not to think it up.\nThe ideas, the analogies, the message—they’re human. Mine.\nWhat AI helped with was structure, clarity, and flow—like a really good editor who knows how to tighten up a paragraph without changing the soul of the story.\nBecause that’s where the line is drawn today:\nAI can assist, but it doesn’t originate. It reflects what’s already known. It doesn’t feel, wonder, or wrestle with ideas the way we do.\nThe librarian can help you find the answer.\nBut it’s still up to you to ask the right question—and do something meaningful with the result.\n","date":"18 July 2025","externalUrl":null,"permalink":"/posts/ai-is-going-to-change-the-landscape-of-work--just-not-how-you-think-it-will/","section":"Archives","summary":"","title":"AI Is Going to Change the Landscape of Work — Just Not How You Think It Will","type":"posts"},{"content":"Ah, the life of a security professional - where our superhero origin story involves developing X-ray vision for networks instead of getting bitten by a radioactive spider. We\u0026rsquo;re the Sherlock Holmes of the digital world, minus the deerstalker hat (although I\u0026rsquo;m sure some of us rock that look during casual Fridays).Let\u0026rsquo;s dive into the world of local admin accounts, where the plot thickens faster than a bowl of oatmeal left out overnight.\nThe Scenario: When \u0026ldquo;Admin\u0026rdquo; Becomes a Four-Letter Word # Picture this: You\u0026rsquo;re an IT admin, living your best life, deploying software and providing remote support like a digital Santa Claus. Life is good. Then suddenly, BAM! A pandemic hits, and your environment goes from \u0026ldquo;mostly in-office\u0026rdquo; to \u0026ldquo;where did everyone go?\u0026rdquo; faster than you can say \u0026ldquo;VPN connection failed.\u0026rdquo; In a moment of panic (and perhaps after one too many cups of coffee), you make a decision that seemed brilliant at the time - create a single local admin account on every system. Same username, same password. It\u0026rsquo;s like giving everyone in your neighborhood the same key to their front door. What could possibly go wrong? Fast forward three years, and you\u0026rsquo;re living in a sitcom where the laugh track is replaced by the sound of security professionals facepalming in unison. Your help desk staff has changed more times than a chameleon in a bag of Skittles, and now you\u0026rsquo;ve got potential rogue admins out there with the keys to your digital kingdom. It\u0026rsquo;s like leaving a \u0026ldquo;Welcome Hackers!\u0026rdquo; mat at your firewall.\nThe Find: Sherlock Holmes Meets PowerShell # Enter our hero: the Local Administrator Group Audit Tool. It\u0026rsquo;s like a metal detector for finding those buried admin accounts, but instead of beeping, it generates CSV files (which, let\u0026rsquo;s be honest, is way less annoying).This script is your digital bloodhound, sniffing out those elusive local admin accounts across your network. It\u0026rsquo;s like playing \u0026ldquo;Where\u0026rsquo;s Waldo?\u0026rdquo; but instead of finding a guy in a striped shirt, you\u0026rsquo;re uncovering potential security nightmares. Remember, \u0026ldquo;You can\u0026rsquo;t secure what you can\u0026rsquo;t see\u0026rdquo; isn\u0026rsquo;t just a catchy phrase - it\u0026rsquo;s the \u0026ldquo;To be or not to be\u0026rdquo; of cybersecurity. And this script? It\u0026rsquo;s your flashlight in the dark, spooky attic of your network.\nThe Caveat: You Can\u0026rsquo;t Find What\u0026rsquo;s Hiding Under the Digital Bed # Now, there\u0026rsquo;s a catch (isn\u0026rsquo;t there always?). You need to be able to \u0026ldquo;see\u0026rdquo; the systems to audit them. It\u0026rsquo;s like trying to count sheep, but half the flock is vacationing in the Bahamas. Luckily, tools like Crowdstrike can help you reach out and touch those remote systems - digitally, of course. No need for awkward virtual hugs.\nThe Solution: Baby Steps to Security Nirvana # This script doesn\u0026rsquo;t magically fix your local admin woes - it\u0026rsquo;s not a digital fairy godmother (though wouldn\u0026rsquo;t that be nice?). What it does is shine a spotlight on where your problems are hiding. It\u0026rsquo;s like having a map in a treasure hunt, except the \u0026ldquo;X\u0026rdquo; marks the spot where you need to clean up your act. Remember, identifying the problem is the first step. The next steps involve actually fixing it, probably some hair-pulling, possibly some colorful language, and definitely some late nights. But hey, that\u0026rsquo;s why they pay us the big bucks, right? (Cue nervous laughter)So, gear up, fellow digital detectives! It\u0026rsquo;s time to don your metaphorical deerstalker, grab your PowerShell pipe, and start hunting those rogue admin accounts. May the odds be ever in your favor, and may your coffee be strong. Find this script (https://github.com/CyberBunny74/LocalAdmin) and more digital treasures at the Cyberbunny74 GitHub repository (https://github.com/CyberBunny74) . Because nothing says \u0026ldquo;serious cybersecurity professional\u0026rdquo; like a GitHub account named after a fluffy digital lagomorph. Happy hunting, and may your networks be forever secure (or at least until the next big tech revolution)!\n","date":"8 February 2025","externalUrl":null,"permalink":"/posts/local-admin/","section":"Archives","summary":"","title":"Find the Local Admins","type":"posts"},{"content":"","date":"8 February 2025","externalUrl":null,"permalink":"/tags/local/","section":"Tags","summary":"","title":"Local","type":"tags"},{"content":"","date":"8 February 2025","externalUrl":null,"permalink":"/tags/script/","section":"Tags","summary":"","title":"Script","type":"tags"},{"content":"","date":"18 January 2025","externalUrl":null,"permalink":"/tags/client/","section":"Tags","summary":"","title":"Client","type":"tags"},{"content":" Unveiling the Truth: The Get-Uptime PowerShell Function # As IT professionals, we\u0026rsquo;ve all heard it before: \u0026ldquo;I swear I rebooted!\u0026rdquo; Yet, somehow, the computer\u0026rsquo;s uptime rivals the lifespan of a tortoise. Fear not, fellow tech sleuths! Today, we\u0026rsquo;re diving into a PowerShell function that will help you uncover the truth behind those dubious reboot claims.\nThe Perpetually Running PC: A User\u0026rsquo;s Tale # Before we jump into the details, let\u0026rsquo;s appreciate some telltale signs that a user might be stretching the truth about rebooting:\nThe computer\u0026rsquo;s uptime is longer than the user\u0026rsquo;s last relationship. There are so many open browser tabs, you can see the heat shimmer coming off the monitor. The desktop has more icons than a Greek Orthodox church. When you ask them to reboot, they just wiggle the mouse and say, \u0026ldquo;See? All better!\u0026rdquo; The last Windows update was so long ago, it was delivered by carrier pigeon. Now, let\u0026rsquo;s arm ourselves with a tool to cut through the reboot fabrications and get to the cold, hard uptime truth.\nIntroducing the Enhanced Get-Uptime Function # Our Get-Uptime function has evolved from a simple uptime checker to a robust, feature-rich tool that can handle multiple computers, provide various output formats, and even log its activities. You can find the full code and documentation for this function in the following GitHub repository:\nGet-UptimeFunction GitHub Repository\nKey Enhancements # Input Validation: We\u0026rsquo;ve added robust input validation to ensure only valid computer names are processed, preventing potential security issues.\nParallel Execution: The function now uses ForEach-Object -Parallel to query multiple computers simultaneously, significantly improving performance in large environments.\nFlexible Output: Users can choose between object, CSV, or HTML output formats, making it easier to integrate with various reporting tools.\nLogging: A built-in logging function helps track the script\u0026rsquo;s execution and troubleshoot any issues that may arise.\nError Handling: Improved error handling provides more informative messages, aiding in quick problem resolution.\nReal-World Applications # In a any organization, this enhanced Get-Uptime function can be invaluable for:\nMonitoring critical infrastructure systems to ensure they haven\u0026rsquo;t unexpectedly rebooted. Tracking compliance with patching and update policies that require regular reboots. Investigating potential security incidents by identifying systems with unusually long uptimes (indicating missed patches) or unexpectedly short uptimes (suggesting potential compromise). Conclusion # With this powerful Get-Uptime function in your toolkit, you\u0026rsquo;ll be able to quickly separate the reboot fact from fiction. Whether you\u0026rsquo;re managing a small network or a large, complex infrastructure, this script provides the flexibility and functionality needed to keep your systems in check.\nRemember, in the world of IT, trust but verify. And when a user insists they\u0026rsquo;ve rebooted, just smile, nod, and let your trusty PowerShell function do the talking. After all, numbers don\u0026rsquo;t lie – even if users sometimes do!\nHappy scripting, and may your uptimes be short and your patches be plentiful!\n","date":"18 January 2025","externalUrl":null,"permalink":"/posts/get-uptime-powershell-function/","section":"Archives","summary":"","title":"Get-Uptime","type":"posts"},{"content":"","date":"18 January 2025","externalUrl":null,"permalink":"/tags/wmi/","section":"Tags","summary":"","title":"WMI","type":"tags"},{"content":"","date":"5 January 2025","externalUrl":null,"permalink":"/tags/port/","section":"Tags","summary":"","title":"Port","type":"tags"},{"content":"","date":"5 January 2025","externalUrl":null,"permalink":"/tags/scan/","section":"Tags","summary":"","title":"Scan","type":"tags"},{"content":"Ah, NMAP. The go-to tool for network administrators and security professionals when they want to peek at open ports. But let\u0026rsquo;s be real - who needs all that sophistication? Today, we\u0026rsquo;re going to explore the art of port scanning using nothing but your wits, a rusty paperclip, and maybe a magic 8-ball.\nThe Ancient Art of Port Divination # Remember the good old days when sysadmins would press their ears against server racks, listening for the faint whispers of open ports? Pepperidge Farm remembers. Why not bring back this time-honored tradition? Simply walk up to your network switch, close your eyes, and let your finger dance across the ports. Whichever one feels the warmest is clearly the most active. Science!\nThe Telnet Tango # Who says you can\u0026rsquo;t use telnet for everything? Sure, it\u0026rsquo;s about as secure as a screen door on a submarine, but it\u0026rsquo;s got charm! Try connecting to random ports using telnet and see what happens. If you get gibberish back, congratulations! You\u0026rsquo;ve found an open port. Bonus points if you can decipher the gibberish and determine it\u0026rsquo;s actually your colleague\u0026rsquo;s unfinished novel.\nThe Ping-Pong Method # Forget fancy port scanning techniques. Just grab a ping-pong ball and write port numbers on it. Toss it at your server rack. Whatever number it lands on, that\u0026rsquo;s the port you should investigate. It\u0026rsquo;s like bingo, but with more potential for accidental DDoS attacks!\nThe Coffee Cup Technique # Pour yourself a cup of coffee and stare into it intensely. The swirls and patterns formed by the cream will reveal which ports are open. Can\u0026rsquo;t see anything? That\u0026rsquo;s because you forgot to add cream, you monster.\nThe Rubber Duck Debug # Explain to a rubber duck which ports you think should be open. If the duck doesn\u0026rsquo;t object, those ports are definitely open. This method has a 60% success rate, 100% of the time.\nOf course, if you\u0026rsquo;re feeling less adventurous and want to stick to more conventional methods, you could always check out this repository of web scanning scripts: https://github.com/CyberBunny74/Web_Scans. But where\u0026rsquo;s the fun in that?\nRemember, friends, port scanning is a serious business. But who says we can\u0026rsquo;t have a laugh while doing it? Just make sure you have permission before you start poking around networks that aren\u0026rsquo;t yours. We don\u0026rsquo;t want any unexpected visits from people wearing suits and sunglasses, do we?\nNow, if you\u0026rsquo;ll excuse me, I need to go consult my magic 8-ball about the status of port 443.\n","date":"5 January 2025","externalUrl":null,"permalink":"/posts/scanning-internal-ports/","section":"Archives","summary":"","title":"Who Needs NMAP? A Hilarious Guide to Port Scanning Without the Fancy Tool","type":"posts"},{"content":"","date":"29 December 2024","externalUrl":null,"permalink":"/tags/disk/","section":"Tags","summary":"","title":"Disk","type":"tags"},{"content":" Disk Space Sleuth: A Tale of PowerShell Optimization # Hey there, tech enthusiasts and fellow script-wranglers! Today, we\u0026rsquo;re diving into the world of PowerShell optimization. Buckle up, because we\u0026rsquo;re about to turn a simple disk space query into a lean, mean, data-collecting machine.\nThe Mission # Our mission, should we choose to accept it (and let\u0026rsquo;s face it, we\u0026rsquo;re geeks, of course we will), is to gather disk information from multiple servers efficiently. We\u0026rsquo;re talking system names, device IDs, and disk sizes - all neatly packaged in a CSV file. Sounds simple, right? Well, hold onto your keyboards, because we\u0026rsquo;re about to kick it up a notch.\nThe Original Script: A Diamond in the Rough # Sometimes, us old-timers have a script that we have used for many years. Many will tell you the wise words of \u0026ldquo;If it is not broke, don\u0026rsquo;t fix it\u0026rdquo;. But sometimes, you do not know it is broke until you fix it. That is what happened to me here. We started with this little gem:\nGet-WMIObject Win32_LogicalDisk -computer (Get-Content C:\\scripts\\servers.txt) -Filter \u0026#34;Drivetype=3\u0026#34; | Select SystemName,DeviceID,@{Name=\u0026#39;Size(GB)\u0026#39;;Exp={$_.Size /1gb -as [int]}} | Export-CSV \u0026#34;C:\\CSVReports\\DiskDrives.csv\u0026#34; Not bad, right? It gets the job done. But in the world of IT, \u0026ldquo;done\u0026rdquo; isn\u0026rsquo;t enough. We want it done faster, smoother, and with more pizzazz. (Okay, maybe not pizzazz, but definitely faster.)\nThe Optimization Journey # 1. Streamlined Reading # First, we swapped out Get-Content for a StreamReader. It\u0026rsquo;s like upgrading from a bicycle to a motorcycle when reading our server list.\n2. CIM for the Win # We ditched Get-WMIObject in favor of Get-CimInstance. It\u0026rsquo;s newer, faster, and doesn\u0026rsquo;t require you to yell \u0026ldquo;WMI\u0026rdquo; every time you use it. (Though you can if you want to. I won\u0026rsquo;t judge.)\n3. Batch Processing # We introduced batch processing, because why query one server at a time when you can query 10? It\u0026rsquo;s like carpooling, but for data.\n4. Parallel Power # By using Invoke-Command, we\u0026rsquo;re now running our queries in parallel. It\u0026rsquo;s like sending out a team of mini-mes to gather data simultaneously. Efficiency at its finest!\n5. Write As You Go # Instead of hoarding all our data and then writing it out, we\u0026rsquo;re now writing to our CSV file in batches. It\u0026rsquo;s like clearing your plate between courses at a buffet - keeps things manageable and reduces the risk of a memory \u0026ldquo;food coma\u0026rdquo;.\nThe Optimized Script: A Thing of Beauty # And now, ladies and gentlemen, I present to you the optimized script in all its glory:\n# Define the output file path $outputFile = \u0026#34;C:\\CSVReports\\DiskDrives.csv\u0026#34; # Remove the existing output file if it exists if (Test-Path $outputFile) { Remove-Item $outputFile } # Use a StreamReader to read the servers file $reader = [System.IO.StreamReader]::new(\u0026#34;C:\\scripts\\servers.txt\u0026#34;) # Process servers in batches $batchSize = 10 $batch = @() while ($true) { $server = $reader.ReadLine() if ($server -eq $null) { # Process remaining servers in the last batch if ($batch.Count -gt 0) { $results = Invoke-Command -ComputerName $batch -ScriptBlock { Get-CimInstance Win32_LogicalDisk -Filter \u0026#34;Drivetype=3\u0026#34; | Select-Object @{Name=\u0026#39;SystemName\u0026#39;;Expression={$env:COMPUTERNAME}}, DeviceID, @{Name=\u0026#39;Size(GB)\u0026#39;;Expression={[int]($_.Size / 1GB)}} } $results | Export-Csv $outputFile -Append -NoTypeInformation } break } $batch += $server if ($batch.Count -eq $batchSize) { $results = Invoke-Command -ComputerName $batch -ScriptBlock { Get-CimInstance Win32_LogicalDisk -Filter \u0026#34;Drivetype=3\u0026#34; | Select-Object @{Name=\u0026#39;SystemName\u0026#39;;Expression={$env:COMPUTERNAME}}, DeviceID, @{Name=\u0026#39;Size(GB)\u0026#39;;Expression={[int]($_.Size / 1GB)}} } $results | Export-Csv $outputFile -Append -NoTypeInformation $batch = @() } } $reader.Close() Write-Host \u0026#34;Disk information has been exported to $outputFile\u0026#34; You can also find the script, just like all the other wonderful scripts you see on this block, from my GitHub repository here.\nThe Takeaway # Remember, folks, optimization isn\u0026rsquo;t just about making things faster. It\u0026rsquo;s about being smarter with our resources, reducing strain on our systems, and ultimately, making our lives (and our servers\u0026rsquo; lives) easier.\nSo, the next time you\u0026rsquo;re faced with a script that works but could work better, channel your inner optimizer. Your servers (and your fellow IT pros) will thank you.\nUntil next time, keep scripting, keep optimizing, and may your disk spaces always be plentiful!\n","date":"29 December 2024","externalUrl":null,"permalink":"/posts/disk-space-sleuth/","section":"Archives","summary":"","title":"Disk Space Sleuth","type":"posts"},{"content":"","date":"29 December 2024","externalUrl":null,"permalink":"/tags/server/","section":"Tags","summary":"","title":"Server","type":"tags"},{"content":"Encryption, the biggest complaint most people have towards cybersecurity other than passwords. In the olden days, users would cringe at that thought of encryption as it would take valuable resources away from the computing power of the servers. Now, with better CPUs and Memory as well as faster Hard drives, encrypting and decrypting are easy. However, the old methods have been compromised. Thanks to how Microsoft thinks, they are still available. This always makes security people nervous.\nI\u0026rsquo;ve put together a collection of five PowerShell scripts that\u0026rsquo;ll make your systems more secure than Fort Knox (well, digitally speaking, at least). The All-Star: DisableAllButTLS12.ps1 # This script is the heavy hitter of the bunch. It\u0026rsquo;s like a digital bouncer, kicking out all the old, insecure SSL and TLS versions from your system\u0026rsquo;s VIP section. But it doesn\u0026rsquo;t stop there – it also shows the door to outdated ciphers and tweaks various security settings. It\u0026rsquo;s basically spring cleaning for your server\u0026rsquo;s security protocols.\nThe Specialists: Disable-SSLv3Client and Disable-SSLv3Server Scripts # Now, if you\u0026rsquo;re still running systems that need these, you might want to consider upgrading your abacus. But hey, I get it – sometimes we\u0026rsquo;re stuck supporting legacy systems that are older than my coffee maker (and trust me, that thing\u0026rsquo;s ancient).\nDisable-SSLv3Client-Multi.ps1 and Disable-SSLv3Client-Single.ps1: These scripts are like pest control for SSL 3.0 on the client side. The \u0026lsquo;Multi\u0026rsquo; version can work its magic across multiple machines, while the \u0026lsquo;Single\u0026rsquo; version is perfect for those one-on-one sessions with a problematic PC. Disable-SSLv3Server-Multi.ps1 and Disable-SSLv3Server-Single.ps1: This one\u0026rsquo;s for all you server huggers out there. It\u0026rsquo;ll disable SSL 3.0 across multiple servers faster than you can say \u0026ldquo;security vulnerability.\u0026rdquo; Remember, folks – using these scripts is like updating your wardrobe. Sure, those bell-bottoms might have sentimental value, but they\u0026rsquo;re not doing you any favors in the security department. Stick with the latest fashion (TLS 1.2 in this case) and you\u0026rsquo;ll be the talk of the cyber town. You can find all these scripts in my GitHub repo here. Feel free to fork, tweak, and make them your own. Just remember – with great power comes great responsibility. And by responsibility, I mean testing these scripts thoroughly before unleashing them on your production environment. Stay secure, my friends, and may your encryption always be strong and your vulnerabilities few!\n","date":"21 December 2024","externalUrl":null,"permalink":"/posts/a-suite-of-ssl-tls-scripts/","section":"Archives","summary":"","title":"A Suite of SSL-TLS Scripts","type":"posts"},{"content":"","date":"21 December 2024","externalUrl":null,"permalink":"/tags/encryption/","section":"Tags","summary":"","title":"Encryption","type":"tags"},{"content":"","date":"14 December 2024","externalUrl":null,"permalink":"/tags/activedirectory/","section":"Tags","summary":"","title":"ActiveDirectory","type":"tags"},{"content":"Ah, Active Directory. That magical realm where users live and sometimes get lost (usually because they forgot their password or clicked on a suspicious link). As a self-proclaimed AD wizard, you’ve likely faced the tedious task of creating new users one by one. Enter this script, your enchanted staff to wield against monotony and inefficiency. Behold: The Active Directory User Creation Script!\nThe Problem # Picture this: It’s a Monday morning. You’re sipping lukewarm coffee while staring at a request for 50 new users. Each one needs a unique configuration—OUs, email addresses, profiles, home drives, and, of course, proxy addresses. By the time you’re done creating them manually, it’ll be next Monday, and someone will undoubtedly ask for another batch.\nYou don’t have time for this. You’re an AD wizard, not an unpaid intern.\nThe Solution: Automation (with a Side of Snark) # This script is the answer to your prayers (or curses, depending on how bad your Monday is). It automates the creation of AD users, taking all the data it needs from a single CSV file. Think of it as handing the script a to-do list and saying, “You deal with it.”\nHere’s what it does:\nReads a CSV File: You fill out a simple spreadsheet, and the script does the heavy lifting. No more typos in names or sifting through AD to find the right OU. It’s all in the CSV. Customizes Everything: Proxy addresses? Check. Password policies? Check. Home directories? Double check. Moves Users to the Correct OU: Each user knows their place in the AD hierarchy (literally). Logs Every Detail: If something goes wrong (spoiler alert: it’s usually a typo in the CSV), the script logs it so you can pinpoint the issue. It’s like your personal AD diary. How It Works # You drop the script into c:\\scripts (because that’s where magic happens). Place your CSV file in c:\\scripts\\data. Name it something descriptive like import_create_ad_users.csv (or “user_magic_list.csv” if you’re feeling whimsical). Run the script in PowerShell and watch as your AD populates faster than a spam inbox. Oh, and don’t worry about the details—it logs everything to c:\\CSVReports\\create_ad_users.log. When a user’s account fails to create, the script tattles on them in the log file. Perfect for pointing fingers at the source of typos.\nThe Unsung Hero: The CSV # Let’s take a moment to appreciate the humble CSV. It’s simple, powerful, and now, your best friend. It can come from any source as long as it speaks I.T.. This one contains columns like:\nGivenName (because users need first names, obviously). LastName (please don’t make it “Smith” for all of them). TargetOU (because not all users belong in the same bucket). ProxyAddresses (yes, plural—users can be fancy like that). It’s so straightforward, even that one guy in IT who still uses Notepad for everything can handle it.\nWhy You\u0026rsquo;ll Love It # No More Tedious Clicking: The script is like your AD intern who works 24/7 without complaints. Customizable: Want users in different OUs? Done. Need profiles and home drives? Easy. This script adapts to your every whim. Error Logging: When things go sideways (and they will), the script tells you exactly what happened. Think of it as your AD therapist. Why Your Boss Will Love It # When your boss sees 50 users created in minutes, they’ll think you’ve mastered sorcery. You can either tell them about the script or let them keep thinking you’re an AD wizard (we won’t judge).\nFinal Thoughts # This script is your golden ticket to avoiding manual AD work and impressing your boss (or at least avoiding their wrath). Just remember: with great power comes great responsibility—don’t accidentally mass-create 5,000 users because you didn’t double-check the CSV. 😅\nSo go ahead, give it a try. Let this script handle the mundane while you focus on more important tasks, like googling “How to Fix AD Replication Issues” for the 50th time this week.\nHappy scripting, fellow wizards!\n","date":"14 December 2024","externalUrl":null,"permalink":"/posts/adding-users-to-active-directory/","section":"Archives","summary":"","title":"Adding Users to Active Directory","type":"posts"},{"content":"Hello, tech wizards and PowerShell enthusiasts! Gather around as we dive into the chronicles of a repository so powerful, it’s practically an IT Excalibur. Welcome to CyberBunny74/ADExportScripts: the ultimate toolkit for taming your Active Directory domains. Think of it as your digital Swiss Army knife—if the Swiss Army had a thing for CSV files and Excel spreadsheets.\nThe Tale of CyberBunny74 # In the mystical world of IT, where forgotten passwords roam and stale computer accounts linger, a hero arose: CyberBunny74. With a keyboard in one hand and a PowerShell script in the other, they embarked on a noble quest to bring order to the chaotic lands of Active Directory. The result? A collection of scripts so ingenious that they deserve their own TED Talk (or at least a spot on your GitHub stars list).\nWhat’s in the Magical Repository? # 1. ADUserExport.ps1 # This script is the Robin Hood of the repository, gathering user data from multiple domain controllers and uniting it in a single CSV file. It’s quick, it’s reliable, and it’ll make you wonder why you ever manually pulled user lists in the first place.\nFeatures:\nFetches user details like DisplayName, LastLogonTimestamp, and AccountExpirationDate.\nCleans up after itself like a responsible roommate.\nUse Case: Need to know which user hasn’t logged in since the invention of fidget spinners? This script has your back.\n2. ADComputerExport.ps1 # Ever felt like your computer accounts were plotting against you? With this script, you’ll gain the upper hand. It’ll sweep through your domain controllers and export details of all enabled computer accounts into a neat CSV file.\nFeatures:\nCollects vital data like IPv4Address, OperatingSystem, and LastLogonDate.\nEnsures no straggler computer accounts slip through the cracks.\nUse Case: Perfect for when you’re auditing your environment and discover a Windows XP machine still lurking in your network. (RIP.)\n3. ADExportWithExcel.ps1 # This is where things get fancy. If the previous scripts are like reliable pick-up trucks, this one is a luxury sedan with all the bells and whistles. It uses the ImportExcel module to export user data into a beautifully organized Excel workbook with separate sheets for each OU.\nFeatures:\nHandles multiple domain controllers with grace.\nOrganizes data into Excel sheets based on OUs.\nEven creates a separate sheet for users who missed the OU memo.\nUse Case: Ideal for those big presentations where you want to impress the boss with your Excel wizardry. Just don’t forget to add a pie chart for dramatic effect.\nWhy Should You Care? # These scripts are more than just lines of code; they’re the antidote to Active Directory chaos. Whether you’re battling stale accounts or preparing for a big audit, this repository has everything you need to stay one step ahead. Plus, the scripts are easy to use, well-documented, and come with built-in humor (well, if you count this blog as part of the package).\nHow to Get Started # Clone the repository:\ngit clone https://github.com/CyberBunny74/ADExportScripts.git Install the prerequisites:\nThe Active Directory module:\nInstall-WindowsFeature -Name RSAT-AD-PowerShell The ImportExcel module (for the Excel script):\nInstall-Module -Name ImportExcel -Scope CurrentUser Follow the instructions in the README.md file.\nFinal Thoughts # Active Directory management doesn’t have to be a grind. With CyberBunny74/ADExportScripts, you can tackle the most tedious tasks with style, efficiency, and maybe even a little flair. So go ahead, clone the repo, and become the hero your IT team deserves. And remember: when in doubt, there’s always PowerShell.\nStay script-savvy,\nCyberBunny74\n","date":"7 December 2024","externalUrl":null,"permalink":"/posts/unlocking-the-secrets-of-active-directory/","section":"Archives","summary":"","title":"Unlocking the Secrets of Active Directory","type":"posts"},{"content":" A Few Items Before We Start # I’ll be the first to admit—I’m not writing most of my scripts from scratch. Most of them start as something I’ve found online, tweaked, and transformed into something that works for my needs. And you know what? That’s okay. They call people like me “script kitties,” and I’m fine with that label. Why reinvent the wheel when you can upgrade it instead?\nConsistency is Key: My Script Environment # One of the most important lessons I’ve learned over the years is the value of consistency when it comes to scripting environments. If you’re scratching your head wondering what an environment is, think of it as the workspace where your scripts run. A consistent environment saves you time and headaches, especially when troubleshooting or setting up something new.\nHere’s how I organize mine:\nScripts Folder: All my scripts live in a folder named C:\\scripts (yes, I’m a Windows user—more on that later). This ensures I always know where to find them.\nData Folder: If a script needs input files, those go into C:\\scripts\\Data. This keeps everything tidy and predictable.\nOutput Folder: Script-generated reports go into C:\\CSVReports. I like to separate log files into a subfolder here called C:\\CSVReports\\Logs for easy reference.\nBy keeping these elements the same across all my projects, I can focus on the “meat and potatoes” of the script without worrying about where to find or store files.\nA Windows Guy at Heart (But Not Exclusively) # I’ll admit it: I’m a Windows guy. Most businesses run on Windows, so naturally, that’s where my career started and where most of my expertise lies. That said, I’ve dabbled in (and sometimes fully supported) MacOS, OS/2, Linux, Unix, and a few other operating systems you’ve probably never heard of.\nBecause of this background, most of the scripts you’ll find here will be written in PowerShell or Batch. That doesn’t mean the functionality won’t work elsewhere, though. You might just need to adapt it to your platform. After all, when you boil it down, it’s all just 1’s and 0’s.\nAnonymization for Security # Let’s talk security for a second. The scripts I share here are going to be anonymized. That means sensitive details like server names, IP addresses, or anything else that could compromise security will be replaced with placeholders. For instance, instead of showing my company’s Active Directory server name as ActiveDIR01 (which, spoiler alert, it’s not), you’ll see something like %DCHere%. This lets you easily substitute your own details without worrying about exposing mine.\nWhat to Expect Moving Forward # I’ll keep this first post short and sweet (well, kind of). If there’s more to add, I’ll pin updates or create follow-up posts. For now, expect a steady stream of scripts that I’ve used throughout my career—each one designed to make life a little easier, and maybe even a little fun. Thanks for stopping by, and happy scripting!\n","date":"1 December 2024","externalUrl":null,"permalink":"/posts/about-my-scripts/","section":"Archives","summary":"","title":"A Journey Through Scripts and Automation","type":"posts"},{"content":"","date":"30 November 2024","externalUrl":null,"permalink":"/tags/blog/","section":"Tags","summary":"","title":"Blog","type":"tags"},{"content":"I am starting a new blog. My intent here is to use the items that I have learned in my past years to store / share what I have learned. I hope this helps someone.\nThe Idea for this comes from NetworkChuck and the \u0026ldquo;I started a blog \u0026hellip;.. in 2024\u0026rdquo; video located at https://www.youtube.com/watch?v=dnE7c0ELEH8. Thank you for the idea.\n","date":"30 November 2024","externalUrl":null,"permalink":"/posts/start-of-the-blog/","section":"Archives","summary":"","title":"Start of the Blog","type":"posts"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]