DevSecOps Engineer, Author, and Mentor

In the first part of this essay, I argued that many conversations about artificial intelligence become more understandable when we stop focusing exclusively on artifacts and begin focusing on the people connected to them. A photograph is not merely image data. A voice recording is not merely a sample. A body of writing is not merely a statistical pattern. Each artifact derives its significance from its connection to a human being. Once that connection is forgotten, it becomes remarkably easy to view people as resources rather than persons.

That observation naturally leads to a difficult question. If consent exists, what exactly is it protecting? At first glance, the answer appears straightforward. Consent protects privacy. Consent protects ownership. Consent protects information. While each of those answers contains some truth, they seem incomplete. The deeper I explored the subject, the more convinced I became that consent protects something even more fundamental: human dignity. Consent reminds us that another person's likeness, labor, voice, creativity, and identity are not ours to use simply because doing so would be useful, profitable, convenient, or technologically possible.

Artificial intelligence places unusual pressure on that principle because it dramatically expands what can be done with the artifacts people leave behind. A photograph can be transformed into thousands of new images. A voice recording can become synthetic speech. Years of writing can be analyzed, modeled, and reproduced in seconds. As these capabilities continue to improve, the central question shifts from what is possible to what is permissible. More importantly, it forces us to confront the uncomfortable reality that those two categories are not always the same.

That is where many of the most important consent questions begin. They emerge in the space between legality and ethics, between capability and stewardship, and between what we are allowed to do and what we ought to do.

Read More

In a post on Documentation and AI , I advocated for the use of Doxygen-style comments when developing and maintaining shell scripts to preserve intent, contracts, interfaces, edge-cases, and context information. An AI wouldn't need to reinterpret how a block of Bash shell script code worked every time it ran. Doing so would provide a pathway by which subtle changes in understanding could be introduced, much like what happens in a telephone game.

Another benefit of that structured documentation technique is the ability to generate usage information for shell scripts. This allows you to automatically generate what is displayed when someone runs your_script.bash --help without having to maintain that help screen yourself.

So, I put together a tool that can accept one or more Bash shell scripts as inputs, generate the help text, and then inject that help text back into the script. Along the way, the incoming Bash shell scripts are minimized so that the finished version is tighter and no longer carries the full volume of inline documentation.

Read More

The first time I seriously considered using artificial intelligence in my professional work, the answer was already decided.

No.

The decision was not mine to make. At the time, I was working on federal projects with significant security and compliance requirements. Public large language models (LLMs) were prohibited. That meant that we couldn't paste source code into prompts, upload documentation, or use project artifacts as context for retrieval systems. Even projects built largely upon open-source software were subject to the same restrictions. While developers across the industry were experimenting with AI-assisted coding, summarization, and research, our path was considerably narrower. The technology was simply too new, and too many questions remained unanswered.

At the time, I viewed those restrictions primarily as a security matter. That was certainly how most discussions were framed. Once information leaves a system, control becomes difficult to maintain. Data can be copied, logged, replicated, retained, backed up, and transferred in ways that are not always visible to the person who originally submitted it. A vendor might truthfully state that information would not be used for model training while still leaving dozens of important questions unresolved. Where would the data be stored? Who would have access to it? How long would it remain? What protections existed against misuse? These were practical questions, and they deserved practical answers.

Yet over time I began to notice something interesting. Security perspectives explained much of the concern, but not all of it. Compliance perspectives explained some of it. Risk management perspectives explained some of it. Data governance perspectives explained some of it. Each framework illuminated part of the picture, yet none seemed capable of explaining why the issue felt important even in situations where no obvious harm existed. A public document submitted to an AI system might contain no secrets, and an open-source repository might contain no protected information. A conference presentation might already be available to anyone willing to watch it online. The discomfort remained.

That lingering discomfort eventually led me to a question I had not considered before. What exactly was I trying to protect?

Read More