The Geometry of AI

“And the whole is greater than the part.” - Euclid

 

AI is all the rage lately and I’ve been thinking about how to frame this in my mind and explain the possibilities and some of the inherent risks to others when needed. Since I enjoy a good analogy, here’s what I came up with. 

 

Plain code, loaded with If...Then, Case, and other branching functions is the Zero-dimensional point; this isn’t AI, but it might appear to simulate it under the right circumstances. Think back to the very beginning of computing and the ELIZA application. (https://en.wikipedia.org/wiki/ELIZA) Honestly, it’s just natural language programming, but back in the day it was impressive and some versions have been documented as passing the Turing test. In my opinion, this is the very basic root of everything AI. As I see it here, the big security challenges are straightforward, as there are limited abilities to interact with users, data, and systems. Here it would be mostly about making sure that any sensitive information obtained by the system is not accessible by those who do not have a need to know.

 

AI concepts begin to get more interesting when we think about Machine Learning, which I consider to be the next geometric step, the One-dimensional line. This is code that works with and manipulates data and can examine it to classify and create models that can be reported on. In my line of work, being able to create and model large datasets or user activity can help us to identify potential security anomalies. Note that the ML model basically organizes and sorts the data, it does not interpret data. For ML, our security concerns are more about protecting the information held in the model.

 

If we want to get to that next step of interpreting the data, that’s what I consider to be the Two-dimensional shape in the form of Large Language Models or LLM. (https://en.wikipedia.org/wiki/Large_language_model) Here we are working with more data, and it is being organized by the tool itself. The LLM “reads” the information exposed to it and creates statistical pattern-based objects which might be text or images. This step is important as it helps the model to understand concepts and relationships for responding to requests.

And this is where it gets interesting. I recently started on a “vibe coding” project which I will be explaining in a later article. As part of this work, I needed to create a data set (a database table) for testing. As the data set became increasingly complicated, it was easier to have the LLM I was using maintain it for me. At first, it would just do some regex as part of some basic search and replace, but as the table got longer and added additional fields, my LLM started writing Python to do the work! Not sure why I was so blown away by this as the LLM had written some testing code to help with troubleshooting. I guess it was because I was working on a database table stored in MariaDB, and not actual code. But I will say it was interesting to watch. As a result, I do have a fun table of identity objects that I can use for testing and product demos.

The last “normal” dimensional concept will be that of the Three-dimensional solid, and I liken this to the concept of Agentic AI. As we have seen in this article, each concept has built upon itself to the point that the Agentic AI, not only models and interacts with data, but can interact with other objects on the network and beyond. To be fair, the LLM does interact with its user and the data itself to make new things, but it doesn’t go beyond the data and the host system. Agentic AI has the potential to interact with other agents to get things done, and that’s where things really start to get interesting.

The basic concept here is that I can instruct my agent to go get something done, let’s say order flowers. I tell it I want flowers for a given occasion, with certain flowers, in a set price range. I can also tell it that these flowers need to be delivered to a specific address by a set date. My agent will have to go out and talk to the floral agent, which might need to talk to the shipping agent. The floral agent and the shipping agent will need to talk to my agent to get paid, possibly by establishing a connection with my banking agent or service. The goal would be to only have my personal agent talk to me to handle any questions not handled in my initial request, but it might need my guidance about anything outside the prompt. In the best model, my agent would continue to learn my preferences about flowers, money handling, and shipping preferences.

What will be the next step? We are already seeing ecommerce (Stripe) and payment industry leaders (Paypal) enter this conversation and place their stamp on how this will work.

It gets even more interesting when we consider the future and additional dimensions of Artificial Intelligence. A Fourth dimensional view will be much like how we visualize shapes like the tesseract. (https://en.wikipedia.org/wiki/Tesseract)  Much the same way that we can have an appreciation of what an advanced shape would look like, we know there will be a difference in how AI conceives its solutions. This means that the AI may not simply have more capability, but more opacity, making it harder to understand. Up to the agentic stage, we can still usually trace the rough path from prompt to action, even if that path is complicated. Now the system begins to reason across time, memory, tools, and other agents in ways that produce useful outcomes without producing explanations that feel natural to human beings. We may understand the goal and observe the result, but not fully understand the shape of the reasoning in between. That is the point where AI stops being merely impressive and starts to appear alien.

Maybe something like telling my self-driving car where to go, how to handle tolls, how to handle low fuel/battery levels, route preferences? Honestly, I’m pretty sure this is low hanging fruit and we see that the self-driving car example is already being addressed by the automotive industry.

At this stage, the security conversation also changes. The concern is no longer just whether the model can access data or call a tool. The concern becomes whether we can govern a system whose decisions are effective, but not intuitively legible. A self-driving car is a simple example. I may be able to tell the car where to go, how to handle tolls, or what route I prefer, but at some point I am trusting a machine to continuously balance safety, law, etiquette, efficiency, changing road conditions, and its own learned models faster than I can follow in real time. That is where the fourth dimension starts to matter.

Part of this is how we choose to “feed” the model.For the car driving example, we also need to think about laws and driving etiquette, which might be slightly harder to define in terms of a model.  For our floral example, there needs to be an understanding that we can only pay with available funds, and the rules of money transfers to prevent intentional or inadvertent fraud and maybe considering the legality of moving flowers across national borders. 

This is why future AI will need more than permissions and prompts; it will need governance, boundaries, and ways for humans to intervene when the logic of the machine stops looking like the logic of the people who built it. I’m thinking that we will need to have some sort of adaptation of Isaac Asimov’s Three Laws of Robotics (https://en.wikipedia.org/wiki/Three_Laws_of_Robotics) For the uninitiated, they are:

1.    An AI may not injure a human being or, through inaction, allow a human being to come to harm.

2.    An AI must obey the orders given it by human beings or other agents except where such orders would conflict with the First Law.

3.    An AI must protect its own existence as long as such protection does not conflict with the First or Second Law.

 

And as Asimov’s stories tell us, how these laws are adapted for specific use cases have the potential to stretch our own concepts of philosophy and science. This means that there is a requirement to monitor compliance with existing security directives as specified in the tool’s governing rules and the governance rules of any organizations that they encounter, either when accessing and processing data or in communicating with other agents and models. And as Asimov’s stories tell us, how these laws are adapted for specific use cases have the potential to stretch our own concepts of philosophy and science.

Note: AI tools were used to help tighten up one part of this document. It’s up to you to figure out where. 

Time for a Ping Story!

“Once more unto the breach, dear friends, once more”
-W Shakespeare

I find it interesting that I have been working at Ping Identity for almost 6 1/2 years, but I haven't really posted a lot of technical content. That's something that changes now.

I'd been planning for a different debut article on the topic but a recent issue gave me a nice opportunity.

I'm preparing for a customer demonstration that involves PingOne, PingDirectory, and the PingOne LDAP gateway. The demo came together fairly easily and everything was running in what I like to call "Demo Quality" That is to say, it worked, but you'd never put this configuration into production. While that is not something that typically bothers me, both PD and the Gateway were not configured to run as a service. As I needed to take my mind off of a different issue, I figured I would set this up while the back of my head worked on the other issue.

In this case PD and the Gateway were running on a Windows 11 VM on my MacBook Pro (It's an M4 and I can't run Server on ARM if you were wondering, yes I know I should use Linux) and figured this would be quick and painless.

Of course it wasn't.

While the installation of the service wrapper worked just fine, the service would not start. Kinda perplexing since everything works as a stand-alone. (It seems though with PingDirectory 11, if you install the wrapper even start-server uses the service configuration, the Gateway does not share this approach and the run.bat does not use the service configuration.)

The error that was presented was interesting to me

WARN   | wrapper  | 2026/01/26 11:14:46 | The 'JAVA_HOME' environment variable was referenced but has not been defined.STATUS | wrapper  | 2026/01/26 11:14:46 | Launching a JVM...INFO   | wrapper  | 2026/01/26 11:14:46 | Java Command Line:INFO   | wrapper  | 2026/01/26 11:14:46 |   Command: "%JAVA_HOME%\bin\java" 

Ok so anyone who has installed PD before (or virtually any Ping self-managed tool) knows that installing JAVA is a must and that properly setting JAVA_HOME and the PATH are essential. Having done this a couple of hundred times I knew I did this already, so I was slightly irritated. 

After checking with some colleagues, I learned something new.

Previously I had only set up the environment variables for the user. This is a pattern that has worked for years, if not decades. But it seems that for the PD and Gateway services to work. Now I need to set them at the System level as well.

Once I had this configured, the services worked just fine. As I learn (usually by breaking things) I will try to share more.

Some thoughts on AI

We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths. -Walt Disney

AI is the next big thing. Is it a wave, a bubble, or here to stay? I wish I knew. I will tell you what I have learned about and from AI over the last few months.

At the end of the day, it’s a tool, and as we all know, the result of using tools depends on the user. Hammers can drive nails or smash your finger. Read a tape measure correctly and your project can look good, do it wrong and nothing fits. I won’t even talk about knives and saws.

On the other hand, we hear all the time about “Vibe Coding” and how easy it is to just have AI build an app for you. I can tell you I’ve probably tried this 5 or 6 times with limited results. When it’s worked, it’s been amazing and when it hasn’t, it’s no fun to work your way through code you did not write yourself and debug it.

Even if you ask AI to document the code, it’s not always easy to figure out what is going on. One of the things that separates professional developers from amateurs (which I most certainly am not a professional developer) is the ability to easily discern what is being done here. (And I’ll talk more about this in a second) It’s even more fun when you’re not as proficient at the particular language in use. For whatever reason, the AIs I have worked with prefer Python, which I’m learning (just not quick enough).

So what makes a good AI coding experience? Well for me, it’s something I have in abundance from my career, the ability to define requirements and specifications. Understanding how to code is not as important, but asking how to define what needs to be coded is very important. As the old joke goes, it’s all too easy to miss on the requirements, as this picture shows:

This reminds me of an argument that I had with my father as I was preparing to enter college. Being from the first generation of computer scientists and engineers, he was dead set against me being a Computer Science Major. He felt that it was more important to Major in some aspect of business, accounting, finance, even marketing and minor CS. This way I would understand why things needed to be coded the way they were and not just how to code them. His experience from the early days of computing had taught him that. However, I was not really interested in business concepts, and countered with a new course of study called Management Information Systems, which combined some aspects of business, computer science, and actual business applications that might be encountered by those in the business world. He didn’t think it was a good idea, so in youthful protest, I majored in Political Science.

OK, so enough of the biographical tidbits, how does this all relate to AI and coding? When defining a task with AI, it’s the requirements and their details that matter more than anything else.

Want to design a system, OK, what does it need to do from start to finish? Anything left as undefined or that you think is generally known is a potential spot for issues. One of the nicer things about AI is that it can be iterative, so as results are displayed and tested it’s easy to add in a feature and say “assume all documents are located in the user’s document folder” than not specifying it and then getting some new code. By the way, I’d also add in a declaration if this is a Windows, Mac, or Linux application since that will definitely affect where the documents are stored, and if it’s supposed to work in any environment, you might want to make this a configurable parameter. If anything, it’s too easy for a novice AI developer to work themselves into a corner by getting deeper into interesting features, than just getting the thing working. When coding under this paradigm, it’s a good idea to establish basic functionality before adding in extra features and functionality (something I’ve learned from hard experience) 

As a best practice, something that I have been consistently adding to my AI Prompts is a clause along the lines of “Identify and address any issues or conflicts with best practices in this specification” I find that the tool will typically present things that I haven’t thought of and dwell on things that are potentially important, but not essential. I was using AI to build some demonstration code that had some security values hard coded and in plain text. Definitely a no-no in the professional world, but good enough for a simple one-off demonstration. So I added to the specification a notice that this was for a demonstration and not for production usage.

At the end of the day, what does this all mean? I’m going to make a few guesses:

    • Writing code manually will become less important, if not outright deprecated. As people get more familiar with AI prompting, it will become irrelevant for creating basic applications and tools. I don’t think that major applications or operating systems will be built this way any time soon, so there’s no immediate worry for professional developers.

        ◦ This doesn’t mean that basic application development will be easy or seamless. Indeed, those who do develop in this fashion will need to be tight when defining specifications and scope. I foresee new teaching methods that will develop and enhance these needs.

        ◦ There’s still going to be a need for professional programmers. Currently, AI works by working with large libraries of information. As AI doesn’t truly create at this point, we still need developers that can create new ways of approaching problems and developing algorithms.

    • We need to carefully examine the security models that will address how our AI tools interact with each other, whether it is for interacting on our behalf with other agents/systems for buying things, doing research, achieving a goal or creating applications.

My thinking is that the overall acceptance of AI as something truly useful and not a bubble depends on how the tools develop and are embraced not only by professionals, but by the average user. Part of this will be the design of the tools, is the head of the hammer too big; making it easy to hit one’s thumb? Can we easily read the tape measure to get correct measurements? And of course, can we adapt AI tools so that they are easy to understand and use? I’m pretty sure we will, but the road ahead could be somewhat rocky.

Schemas and Some Elements of LDAP History

Note: all trademarks mentioned in this blog are the property of respective owners.

I've been meaning to write this entry in one form or another for over 20 years. Glad I finally got around to it.

LDAP has been around since 1993, while Microsoft's Active Directory was introduced in 2000. During this time, Active Directory has become a virtually universal constant in organizations worldwide. Approximately 90% of the Fortune 1000 use it. It's hard to escape from it. But there is a definite appeal to setting up additional Directory Service instances from Microsoft or other providers. Setting up these additional instances helps to properly segregate different user types (employees, customers, vendors, etc.) and, particularly in the Active Directory use case, helps manage licenses and keep all OS and Application infrastructure accessible by Active Directory out of prying hands.

Herein lies the issue at hand. For its own reasons, Microsoft does not use the same object classes as standard LDAP. For those unfamiliar with LDAP, an object class is a grouping of attributes. Object classes facilitate the definition of users, groups, and other components of the LDAP structure, thereby introducing some organization to the overall schema.

Standard LDAP uses the inetOrgPerson as the basic definition of a user, while Active Directory uses the user. Most of this grew from the basic organization of Active Directory, along with the additional information required by integrating Microsoft Exchange back when it was an on-premises application. Of course, as the two concepts evolved, differences cropped up that I need to reference from time to time. To make this easier, I'm listing the most important differences here. I've listed the standard LDAP attribute first, followed by the Active Directory attribute.

• jpegPhoto -- thumbnailPhoto
• secretary -- assistant
• street    -- streetAddress
• uid       -- typically not used

I'm sure there are a few others, and I can see updating this list as things change in the future. Also, the uid attribute is typically used in Active Directory when it is being synchronized with a more standards-based LDAP, as it usually uses uid as the primary identifier as opposed to cn when building the entry's distinguishedName. It's also important to remember that the value stored in userPassword is not encrypted, but rather it is a hashed representation of the password. (This article provides a nice description of the process) This means that there is no way to decode this value and setting it typically requires an SSL connection.

One final note here, I've pointed out some differences between Active Directory and LDAP. This is not necessarily a criticism of Active Directory. Active Directory is a proprietary evolution of the original LDAP standard for some of the reasons I mentioned above and more. Standard LDAP is just that, LDAP based applications more closely adhering to RFC2798 and typically being a "descendent" of the original AOL-Netscape-Sun Directory Server code.

Let me know if you have other attributes that should be added to this list.

Identity Management just isn’t what it used to be

 

It feels like Identity Management, whether we are discussing managing employee or customer identities, that it’s not just about managing user names and passwords. Of course, this has been the case for several years. But those of us in the industry are realizing there is a new paradigm where suspicion is the new normal, and this means that everyone involved needs to find new ways to manage and operate in this new model.

The recent Scattered Spider and related attacks are hitting us where we are most vulnerable, the intersection of customers and support, using social engineering to get organizations to reset passwords, along with standbys such as adversary-in-the-middle tactics.[i] Microsoft has also done a great job of describing its tactics and overall strategy.

As a result, the efforts of the Scattered Spider group have done an excellent job of making anyone involved in IT Support and Security very concerned, and have left their customers feeling overwhelmed with doubt and insecurity. “Is this user who they say they are?” is a bigger concern than ever before.

There is one thing that has become abundantly clear for both organizations and customers: Suspicion must be the new normal. It’s a sad, but true reflection on the state of things right now. For customers, it means manual verification of information requests. Do not submit or provide data over the phone without independently verifying that they are communicating with the right people. Of course, this means separate phone calls or other interactions, which means in complicated scam scenarios that this might not be enough, and of course, it slows everything down. It’s really nothing less than a new form of digital terrorism.

For the large organizations, it means that ensuring both employee and customer security is even more critical than ever. Ensuring that employee and customer data is properly segmented and that proper entitlement governance policies are in place is more essential than ever. Additionally, new patterns should be considered for verifying incoming user requests. The most promising method is using stronger identity verification mechanisms, such as liveliness checks, and when the strongest measures are called for, submission of government documents such as ID Cards, Driver’s licenses, and passports. This, of course, can unfortunately increase authentication and authorization friction in areas where there had been motivation to reduce or eliminate it.

There is hope that the use of concepts in Self-sovereign identity will make this verification easier through the encapsulation of identity-related data via an identity wallet secured by technologies such as blockchain. However, this is still an evolving, niche technology.

While we wait for this technology to mature, it is crucial for organizations and individuals who digitally interact with them to exercise caution and remember that when it comes to protecting one’s digital identity, “Paranoid people live longer.[ii]”

---

[i] https://www.cybersecuritydive.com/news/scattered-spider-expands-tactics-recent-hacks/753220/

[ii] I’ve used this expression for over thirty years of my IT career. I can’t believe it has taken me this long to use it in a blog entry.

From Toll Roads to Tokens: The Road Rules of Identity

Recently, I found myself comparing Identity Management to the New Jersey Turnpike—a stretch of infrastructure that demands continuous maintenance, monitoring, and support. The more I thought about it, the more the analogy seemed to hold up on multiple levels.

Consider this: when you enter the Turnpike, you're authenticated—thanks to your EZ-Pass RFID reader. You authorize yourself to use the service by paying the toll¹. Your presence on the road is uniquely identified through a combination of your EZ-Pass ID and your vehicle’s license plate. Similarly, in Identity Management, we combine multiple identifiers to authenticate users and authorize access.

There's even a form of fine-grained authorization at play. Your driver's license determines which type of vehicle you’re allowed to operate—semi-trucks, motorcycles, passenger cars—all of which come with their own set of permissions. Identity systems do the same by assigning entitlements and roles based on user attributes and context.

We can stretch the analogy further. Think about drivers from other states or countries using the Turnpike. They bring their own credentials, but the system recognizes and allows them to operate—a real-world version of Single Sign-On (SSO). Once authenticated, drivers manage their journey: choosing routes, switching lanes, adjusting speed—just like identities that evolve, shift roles, or gain new permissions over time.

But perhaps the most vital component in this infrastructure? The on-ramps and off-ramps.

In our analogy, these represent connectors to other roads—other systems. On-ramps lead drivers onto the Turnpike (onboarding), and off-ramps take them to their destination (offboarding). In identity terms, they’re links to enterprise applications. Some lead to robust, high-speed interstates (modern apps), while others connect to older, more narrow routes (legacy systems). Despite their differences, all are part of the same interconnected digital landscape.

If these ramps are blocked or broken, people can’t get where they need to go. The same is true in Identity Management. Disrupted connectors—whether due to outages, outdated protocols, or rigid infrastructure—can prevent users from accessing critical resources. That’s why flexibility is key.

Just as highways need multiple lanes, alternate routes, and regular maintenance, identity infrastructure must be resilient. It needs to support remote access, cloud redundancy, and failover mechanisms. Whether through replicated data centers, leveraging SaaS service, or just having a well-designed backup plan, your identity architecture must ensure users can always reach their destinations.

In short: smooth identity operations are just like smooth traffic flow. It's all about seamless access, clear pathways, and ensuring the road is always open.







¹ In the pre-EZ-pass era, one paid the toll on the Garden State Parkway, another important piece of infrastructure with a token, but we won’t get into yet another roadway and it’s analogies here ☺.

The Goldilocks Syndrome

 

“Then Goldenlocks sat down in the chair of the Great, Huge Bear, and that was too hard for her. And then she sat down in the chair of the Middle Bear, and that was too soft for her. And then she sat down in the chair of the Little, Small, Wee Bear, and that was neither too hard nor too soft, but just right. So she seated herself in it, and there she sat till the bottom of the chair came out, and down she came plump upon the ground.”[i]

I’ve been making this observation formally ever since I started in the software field at a company called Magic Solutions back in the late 90s and probably informally before then. You see, it’s been my experience that when organizations roll out new enterprise concepts, particularly in IT and more specifically in IT Security and Governance, it goes through at least three revisions. I’ve seen this happen in several models whenever there is some sort of organizational hierarchy. In my Help Desk days, it was about Ticket Subject Organization, in Identity it’s usually the organization of the Directory Service (Security Groups and Organization Unit structures) or role/entitlement hierarchies.

For the record, I’ve been involved in all of the scenarios listed below, and I’ve been confident I nailed it nearly every time. As I’ve become more experienced, I mention that these structures will most likely change over time and that the first time is seldom the charm.

The first one is usually pretty much what the organization thinks they need. This might be in consultation with experts either during the sales process or when working with the implementation specialists. This frequently suffers from a lack of flexibility, in that not all use cases have been properly considered and weighted. It’s good enough for now, and the project to review how things are configured is pushed to the next version of the application / architecture review.

The second time around, the organization is looking to be flexible, so that any potential scenario can be handled. Now we have the opposite problem, where different parts of the organization have too much control and the solution becomes too cumbersome and there is little to no organization. It’s complete anarchy, audit logs become so incomprehensive that they border on being meaningless, and nobody is happy.

At the third time through the process, I believe that we are starting to maybe see a proper solution that has structure, and is somewhat flexible to new scenarios. In terms of our introduction quote, it’s not too rigid, and it’s not too open, but just flexible enough.

Sometimes this is because the structure is more open, or because there’s a stronger change control process in place. Sometimes it is because the organization itself has changed, changing in size, complexity, governance needs, or just a plain old change in culture. Change will still occur, but with the lessons learned the process should be more manageable.

---

[i] https://en.wikisource.org/wiki/The_Story_of_the_Three_Bears_(Brooke) That’s how this version spelled it. Emphasis is mine.