Agentic Authority: Can Your AI Agent Prove It Was Allowed?

This is a lightly edited transcript; quotes shown on screen in the video are verbatim.

0:42Intro

Dr. Med Mehrbod: Hey everyone, this is Dr. Med, and here is Elementera Talk. Here we talk about cutting-edge technology trends with industry and academic leaders. Today I'm joined by Jeremy Blackburn, founder and CEO of ChainIT.

AI agents are starting to buy, pay and sign on behalf of businesses, which raises a simple question: how do you prove an agent was actually allowed to do what it did? ChainIT calls that agentic authority, and Jeremy, you're going to explain it to us today. Jeremy, thanks for being here with us.

Jeremy Blackburn: I appreciate the opportunity. It's nice to be here.

1:15What is agentic authority?

Dr. Med Mehrbod: All right. Let's start with the basics. In plain terms, Jeremy, what is agentic authority? And why did ChainIT decide to build its platform around agentic authority?

Jeremy Blackburn: Sure. One of the fundamental principles of ChainIT is to make a verifiable connection between the physical and digital worlds. That is the base, fundamental architecture of ChainIT. As part of that, as we move into this age of agentic, we recognized early on that we were going to have to be able to verifiably connect agentic agents to whom they were acting on behalf of. In fact, that was one of the founding principles of what we were building ChainIT to do: Web3, agentic, and then PQC [post-quantum cryptography].

So in the very simplest terms, agentic authority is the verifiable right of an AI agent to act on behalf of a specific person or organization. But the important part is it has to do that within defined limits and under conditions that can be independently validated. There's a really fundamental distinction between what technology can do and what it's authorized to do. And I think that is one of the key takeaways here: just because an AI agent can do something doesn't mean it has the authority to do that.

2:35Why an agent needs authority to pay

Dr. Med Mehrbod: Absolutely. And I'll get back to that in a minute. So when an AI agent makes a payment, why do we actually need authority for a specific agent?

Jeremy Blackburn: I think the payments and financial industry has spent decades developing ways to authenticate users, protect passwords, secure wallets and verify different digital signatures. A lot of those technologies establish access or possession of credentials, but they don't necessarily establish the legal authority to act. I came from a very diverse background of banking, construction and other regulated industries. In those businesses, you learn very quickly that having access to an account doesn't mean you have the authority to spend the money in that account.

One of the easiest ways to explain this is to think about a corporate office. An employee might have the key to the CEO's office, but that doesn't give the employee the authority to sign a $10 million agreement on behalf of the company. AI agents present the exact same problem, except they're capable of executing thousands of transactions autonomously and even simultaneously.

So we built ChainIT around verifying identity, organizational authority, compliance, which we haven't talked about yet, and the conditions governing the execution. Those are the foundational requirements of legitimate commerce. ChainIT didn't invent authority. We verify its source, we establish its scope, and we validate that it remains effective when the action occurs.

4:03Where authentication stops

Dr. Med Mehrbod: I suspect some of our listeners may be thinking, well, we already authenticate our agents, so we are covered. So my question is: where does authentication stop, and where does agentic authority start?

Jeremy Blackburn: Sure. A lot of what I've seen proposed as far as agentic authority is really cool. I can geek out on the tech and the cryptography on it, but they all fail to prove the most important thing: that the agent had legitimate authority to move that money at the time of the transaction.

A login establishes the credentials that were accepted. One of the things that we talk about extensively in ChainIT is that there are no passwords in ChainIT. Your face is your password. In other words, think of a password like a key to a lock. That key can be stolen, it can be shared, and the lock itself can be hacked. And just because you have the key and can get in the lock doesn't mean that you should be able to do that.

If I have a key to your house, even if you gave me that key, and I go to your house, open the door and go in, does that make it my house? Does that mean that I can rent it, live there or sell it? The answer, of course, is common sense: no. Well, that's what passwords are. They're keys to locks. And by the way, I could have done the same thing: I could have stolen the password, you could have shared it with me, or I could have hacked it. But just because I have the password, the key, in the digital world doesn't mean that I have the right, the authority, to transact or do business behind what that key was protecting.

That's why with ChainIT, we use a five-factor biometric authentication as a password. In very technical standards, those passwords and the keys that are involved in the cryptography are actually stored in the self-custody wallet of the individual. In other words, the individual's face is the key. It's a biometric attestation to access and to grant authority. So, in that previous example, having the password doesn't prove that the person or the organization whose assets are being transferred actually authorized that specific economic activity.

And AI is very adept, as we know, at impersonations of voice and passwords. If it's a static set of data, AI is likely going to be able to replicate it or compromise it. So, if you consider an organizational MPC [multi-party computation] wallet, multiple parties may participate in controlling those cryptographic keys, and a signing threshold may be satisfied. That's very valuable, don't get me wrong.

But a valid MPC signature doesn't inherently prove that the participants had corporate authority to approve the transaction, that the transaction falls within their delegated limits, or that the underlying compliance conditions were satisfied at runtime. So while the cryptography can be perfectly valid, the transaction can be unauthorized. That's the distinction that ChainIT addresses. A valid signature proves something was signed. It doesn't necessarily prove that the signer had the right to authorize what was signed.

7:21One transaction, step by step

Dr. Med Mehrbod: Okay, interesting. Can you walk us through one transaction, a real one? A verified person or company delegates to an agent: what gets written into that token? Counterparties, spending limits, time windows, terms, or what?

Jeremy Blackburn: Yeah, sure. As I mentioned, my background is a lot in construction, so a lot of the examples that pop into my head are related to that. Consider a commercial lender managing construction draws. That is a very detailed, very labor-intensive process, especially if they're dealing with the AIA G702/G703 process, which is used for a lot of the larger projects. That can take whole departments and take weeks, if not a month. In fact, the average draw time is a 30-day window from the time of submission until execution. And I think agentic agents have a real opportunity there to expedite a lot of those processes.

Let's take a large commercial project and imagine that project is going to involve a lender, a developer, a general contractor, dozens of subcontractors and suppliers, logistics and lots of lien holders: disparate parties that have interrelated activities, but are independently owned and managed. Now imagine that an AI agent is managing the payment disbursements, it has access to the lender's payment APIs, and it can even initiate transfers.

A contractor on a large project submits a $250,000 draw request. The agent would confirm the invoice exists, match it against the project and initiate payment. Technically, that sounds like an improvement, and everything works. But what if the contractor's authority was terminated yesterday? What if you kicked him off the job site? What if the draw required an executed conditional lien waiver? What if the payment exceeded the authorized amount? Or what if the contractor's bank account had been fraudulently changed?

All of those are runtime problems. The agent could successfully transfer the money while violating the governing agreements, exposing the lender to loss or litigation. I've operated in both construction and banking extensively, and those aren't hypothetical categories of risk. That is what happens on construction disbursements, and they involve so many independent controls, which is what has made them so difficult.

Now, with ChainIT, we can connect those parties. We can connect the contractors, vendors and suppliers through their ChainIT organizational ID. In that process, we establish organizational authority. In other words, who has the authority? The individual, not an agent. And then the [individual] can designate that authority to an AI agent. But who has organizational authority inside the business, the general contractor, for example, to authorize agreements and issue compliance checks or lien releases, so that the payment execution happens in one governed transaction? AI can assemble and initiate the workflow, but it cannot substitute its own judgment or perceived authority for the verified authority and conditions that are required to release the funds.

In every large construction project I've been involved in, it's not just an invoice. There's an invoice approval, which probably requires a bank inspection or a local government inspection, then you have to get a conditional lien waiver, and then after the payment's made, an unconditional lien waiver. All of that can be automated in ChainIT. With instant payment rails, the consequences are more significant as well, because the opportunity to stop a mistake after the payment execution is dramatically reduced. In other words, once that RTP [Real-Time Payments] transfer or that wire is sent, your ability to fix a problem goes down substantially, because they've already got the money.

Inside of ChainIT, the requirements are verified before the money moves. The authority, the inspections and the lien waivers are all in place, and it manages that programmatically, meaning that ChainIT manages those things to make sure they're done before the money moves. And that's a huge improvement over today's processes.

11:32Approve the transaction, not the agent

Dr. Med Mehrbod: Absolutely. I love how your rare combination of construction and banking background made it so simple for everyone to understand. That's great. Now, let's move on a little bit. If a payment fails, or if the payment details change after approval, the original approval no longer applies. So why bind approval to the exact transaction instead of the agent?

Jeremy Blackburn: So, just to restate your question: why bind the approval to the process? Interestingly enough, payments are usually the beginning or the end of a process. You make a payment and then you get the good or the service. Or you're provided the product, good or service, and then you make a payment. That payment is just one part of that entire process. It either begins or ends it in most cases.

So if you're just approving the agent, the agent would then have to be able to approve all of those individual conditions, requirements or milestones. That's why we bind the payment to the transaction: the payment is a part of it, not the entirety of it.

So the agent could prepare the transaction, and all the required checks pass. But before execution, let's say that the destination wallet address changes. At the beginning of the process, we're going to designate a bank account for that general contractor. But like in the previous example I mentioned, his bank account information changes because he switched banks or there was a problem with his account. This happens all the time. If the authorization only applies to the agent's identity, the agent might still make the transaction to the first account, because it hasn't been able to modify the credentials or authority at runtime. And that's a fundamental security weakness.

So instead of approving the agent to make the payments, you need to authorize the entire transaction at runtime, with authority and with compliance. The approval should be cryptographically bound to the material transaction parameters: the payer, the beneficiary, the amount, the asset or the currency, the destination, and all of the other applicable execution conditions. A cryptographic digest can represent that exact transaction instruction. If a material parameter changes, the digest changes, and the prior approval no longer matches what actually exists at runtime. Then the transaction would have to be evaluated again.

This also addresses substitution attacks, where an attacker attempts to replace an approved transaction with a different one between authorization and settlement. This happens a lot in real estate closing transactions. Think about a traditional signed contract. You wouldn't allow someone to change the purchase price or the counterparty after the execution and still claim that the original signature authorized the new terms. Digital commerce shouldn't operate under a weaker standard.

We authorize the transaction the principal actually approved, not whatever transaction the agent ultimately submits. And by changing the authorization and authentication from the agent to the transaction, we can manage all of those variables that are going to occur in the real world that exists today.

14:46ChainIT, end to end

Dr. Med Mehrbod: Interesting. I like how you view it as a process rather than just a one-off thing, one single transaction that takes place. So we need to look at it holistically, and we need to authenticate the entire process as opposed to just one portion of it.

Jeremy Blackburn: And you just gave the best pitch for ChainIT there is. ChainIT isn't just the payment. We can process payments on literally any rail: card, RTP, wire, SWIFT, ACH [Automated Clearing House], stable currency, stablecoin. We're natively Web3, so stablecoin is our native language. We can process the payment any way you want.

But again, we also do identity for the individual and the organization, and we do that to a source of authority or truth. Here in the U.S., it's to the DMV, and to the Secretary of State with IRS verifications, plus additional compliance and regulatory checks. We have extensive verification on the driver's licenses and a biometric match. As I mentioned earlier, there are no passwords, and in order to achieve those standards, we have a NIST [National Institute of Standards and Technology] Level 2 certification. There are hundreds of fraud checks that occur on the driver's license and on the biometric template we create, matching that to the driver's license and matching that to the DMV.

All of that identity is just the first part. Then we establish authority. We then run compliance. We then do the contract management. We then do the consideration, or the payment disbursements. And then, ultimately, we produce that in a final, immutable record, meaning it can't be changed, for future verification or validation and compliance audits, things of that nature.

16:23What a regulator can verify

Dr. Med Mehrbod: Got it. Thank you. So now, let's fast forward six months after the entire process is completed, and authenticated, of course. A regulator may ask: who approved an agent's payment? What does ChainIT hand them, and can they check it without taking ChainIT's word for it?

Jeremy Blackburn: We should be able to provide a verifiable chain of evidence showing how the transaction became authorized. That includes the identity of the principal, the organization, the governing source of authority, the delegation to the agent, the applicable limits, in other words that the transaction was within the limits, and the approval and compliance decisions associated with the transaction.

I know there's a lot of talk right now about agentic authority. I think we're the only ones talking about agentic compliance: being able to link or connect, in an immutable way, the agent to the individual or organization, not only for authority, but for compliance. And we can run that in real time.

We also want the evidence to establish the relevant sequence of events: when the authority was granted, and what was valid when the transaction occurred. Were there additional approvals that were required and obtained, and what was the instruction ultimately executed against? ChainIT's approach uses cryptographically verified records and immutable transaction evidence, rather than relying on application logs. So an appropriately equipped independent auditor should be able to validate the signatures, the record integrity, the transaction binding and the supporting evidence, without simply accepting something from ChainIT that says the transaction was authorized and compliant.

But there is a really important distinction there. Cryptography can prove the evidence hasn't been altered, and that specific credentials signed it. The legal authority itself must still be supported by the underlying governing records and authoritative sources. That's why we connect the two worlds. That's why we have Web3 for those immutable records, meaning that they can't be changed, and why we use agentic, authority and compliance to effectuate the process automation that we have inside of ChainIT.

So the goal isn't merely to tell a regulator that the transaction was compliant. It's to provide the evidence necessary to independently establish why it was permitted at that time. The technical qualification is that independent verification of historical revocation status, timestamps and underlying authority requires the relevant signed evidence and historical state to be retained or independently accessible. So we are able to confirm the current export and verification capabilities before promising a specific audit package. That was a mouthful, but basically it means, in the simplest terms, we can prove who acted, that they had authority, and that they were compliant at the time the transaction occurred.

19:17Compliance without friction

Dr. Med Mehrbod: Interesting. I want to tap a little bit into the topic of compliance. Typically, we have a trade-off when it comes to software systems. Whenever we try to go by stricter regulations, sometimes we see things get complicated on the user experience side. How do you make sure that the user experience is still easy enough for the users of your clients?

Jeremy Blackburn: Yeah. In the software world, that's called friction. What we try to do inside of ChainIT is make it as easy and friction-free as possible. For an individual that's onboarding with ChainIT, and for an organization, we want as little input from you as possible. In other words, we want to verify and create your identity from sources of authority: again, the DMV and the Secretary of State.

For an individual, one of the things that we filed a trademark on is "Minted in a Minute," meaning that our expectation is you'll be able to create your ChainIT ID as an individual in a minute or less. Once you've downloaded the app, you're literally going to scan the front and the back of your driver's license. We're going to perform all those fraud checks, and it takes seconds. We're then going to capture a selfie. Again, seconds. Our software and applications are going to compare that selfie to the driver's license, access the DMV, verify you are who you represent yourself to be, and then create that permanent, on-chain ChainIT ID that can't be altered. At that same time, we're creating a wallet. Your identity goes in the wallet, and you can then validate yourself through a biometric confirmation for future transactions.

For a business, it's much the same. In that case, we do ask for your legal business name, your EIN [Employer Identification Number] and your state of incorporation. At that point, we're going to access the Secretary of State. We're going to pull back certified articles of organization, your corporate documents. We're going to pull back a certified certificate of good standing. In other words, we're going to verify that your business is, in fact, registered and in good standing, meaning it hasn't been revoked and the business hasn't ceased: its current state, if you will.

Then we're going to do that same individual ID process for the officers and directors that are listed with the Secretary of State. They're going to represent that these are the owners of the company. They're probably going to upload a stock ledger or a membership document. Then those individuals are also going to biometrically onboard, and they're going to attest that they are, in fact, the officers and directors. In other words, they're going to biometrically execute corporate resolutions.

Through this process, we're going to establish beneficial ownership and the authority of the officers and directors to operate the company. They can then delegate that, through biometric attestation, to employees for specific tasks, transaction amounts and functions inside the company. In that same process, they can delegate that authority to an agent. They can all audit the authority of the agent, the employee, the officer and the director, ultimately up to the beneficial ownership of the company.

So that process for us is a lot of accessing records and importing the data, and then you biometrically verify and validate that it is, in fact, the current and up-to-date information. It is, I think, the easiest and most friction-free process that exists to onboard into a Web3 identity, for either you or your business.

22:44When the AI makes mistakes

Dr. Med Mehrbod: Okay, very interesting. So basically, minimal input from me as a user, but maximal process going on behind the scenes, making sure that there's no trust. I know that's your motto. And you're going to verify everything. Great.

When we talk about agentic authority, well, AI agents are AI. One thing we are sure about with pretty much all models is that they make mistakes. Basically, you're providing authority to an AI agent, which may make mistakes. How can you actually explain that?

Jeremy Blackburn: Well, if the AI agent itself is making mistakes, then that would be up to the LLM [large language model] that created it, whether that's Claude or Muse, Grok, any of them, Gemini. There are some amazing AI models out there now. But I think what you're really asking is this: an AI agent model is usually taking a bunch of input and then giving us its best guess or estimate, so it does make mistakes. How do we control those mistakes inside of payments? In other words, if instead of a $25,000 payment it makes a $25 million payment, which has happened in banking before, how do we prevent that?

One of the things I would say is that these AI models are exceptionally useful for the interpretation of information, analyzing documents, negotiation, planning and identifying the next action. But they're not inherently reliable authorities for determining whether a legal delegation exists, or whether a payment satisfies a binding agreement or a binding corporate resolution. An AI model might conclude that a $40,000 payment is reasonable because the invoice appears legitimate and the vendor is part of the corporate infrastructure; it's an important vendor. But that's irrelevant if the agent's delegated spending limit is $25,000.

In our platform, that limit isn't a suggestion. We separate the intelligence that proposes an action from the governed execution controls that determine whether that action is permitted. In other words, we establish rules and guardrails for the agent to operate inside of. The agent can recommend a payment, and it can even assemble the transaction, meaning it can put together the RTP transaction or the wire. It can even request an exception inside of the guardrails or the parameters that have been established. But the final execution decision must satisfy the independently defined and verifiable rules. Is the agent authorized to transact for this type of transaction, to this type of vendor?

Inside of ChainIT, you can be very specific. You can establish rules for the amount of the transaction, the type of transaction, the vendors it can approve, or the payments it can initiate. You can set parameters for certain times of the day, so temporal references; from certain devices, whether they're trusted or open public devices; or from a specific location. The payment might be related to, for example, a logistics delivery. We need a biometric verification from the shipping and receiving clerk, and that biometric attestation needs to confirm at that time that he's a current employee of the company. It needs to confirm that it's during business hours, and it needs to confirm that it's at the geolocation, in other words, the address of the company. All of that can be set as requirements inside of ChainIT.

I think that's particularly important because AI models can be manipulated through prompt injection, compromised documents and even incorrect contextual information. We don't want an agent interpreting its way around the authority it was given. So the AI can decide what it wants to do. It cannot decide what it has the right to do.

26:46Guardrails that chain the agent

Dr. Med Mehrbod: Okay. So, in a sense, I can say ChainIT is going to put some external guardrails in place. ChainIT is going to chain the agent. It's not going to do whatever it wants, even if there's a 0.001% chance of a mistake.

Jeremy Blackburn: Yeah. ChainIT actually stands for chain infrastructure technology, and we definitely view ourselves as infrastructure. So we are going to set those guardrails that an agent can't go outside of. If the guardrail says that it can't exceed this amount, it can't exceed that amount. If it can't make payments outside of this time, or away from this location, ChainIT enforces the rules and guardrails that are put up.

Inside of ChainIT, for the individual ID, the ChainIT ID, there are over 100 attributes that you can configure in a variety of ways to gate an agent: location, time, distance from a location. And inside the business or organizational identity, there are over 300 attributes that you can use to gate or control that agent.

What ChainIT does, through the connection of the physical and digital worlds, is allow things such as location, and even unique object identification inside the physical world, the real world that we live in, to be connected to the digital world, and then use those attributes to gate the agent. In other words, take something as simple as a product that has a barcode or a serial number. In order to complete this transaction, that object token, because we can tokenize almost anything in ChainIT, events, products, services, needs to be verified at the runtime of the transaction by an authorized employee at the business location.

And even inside that little description I just gave, we can say that it's an exact location or an approximate location. In other words, you can zoom in and out on location inside of ChainIT. We have really made the features and functionality both very broad and deep, meaning that there are a lot of features, 300 plus in the organization, and each one of those has many different levels that you can use to gate the agent itself.

A classic one for an individual is for financial transactions. The ChainIT ID actually has 11 levels inside of ChainIT, and those levels are based upon how you created your ID. Was it through a driver's license or a passport? Where did you create the ID? Was it at the address on your government-issued ID? Were we able to retrieve the image from the DMV that was issued at the time of the driver's license? Not every state provides that. And so the ID is graded.

For a lot of the financial transactions, what our banks and lenders require is that you have created your ChainIT ID at the address on your driver's license, and that you're executing their loan documents, again through Pactvera, with biometric attestation, during a certain time, because they want it during business hours, at the location on your driver's license. So they're able to verify that you executed those documents through your biometrics, liveness, location, device ID, all the factors we use, at the registered address, if you will, where you live, during a certain time. Then, if those conditions are met, an AI agent could fund the loan, but only if those conditions are met. There are actually a lot of other conditions it can check at the same time, and then manage those processes and outcomes.

Another really easy one is in that example I just gave. When that loan is funded, the borrower would be able to identify where the funding goes. We've already talked about it: we can do push-to-card, we can do wire or SWIFT, ACH. Well, ChainIT is connected to those sources of authority, so we would be able to verify the bank account is actually in the name of the borrower. If you're the lender, that's what you want. You want to be able to fund the borrower to their bank account, so you know that they received the consideration, the funds. And we can do all of that programmatically.

If the account wasn't in the name of the borrower, then that would be a gate that would stop the transaction, and it would prompt the borrower to identify an account that they were a signer on or an owner of. The technology that exists today allows us, I think, to do a much better job of controls. I think that with the proper infrastructure and foundation, the vast majority of fraud, I'd like to think all, but the vast majority for sure, can be eliminated, because the only access to money movement would be from verified parties with authority. And that authority would extend to verification of tax records, business documents, bank accounts and transaction amounts.

So I do feel that AI, while it's often felt to be a little intimidating or even scary, is going to make things a lot better. It's going to improve a lot of processes that exist right now, today.

31:57What banks and fintechs are asking

Dr. Med Mehrbod: And I want to say that I definitely agree with that, 100%, as an AI company and as someone coming from an AI background, with the right harnesses, which you have in place.

Jeremy Blackburn: We agree to agree.

Dr. Med Mehrbod: We do. Jeremy, ChainIT just presented its agentic Web3 Complete Commerce Architecture at TOKEN2049 week, and it's heading to, I guess, Money20/20 USA. What are banks and fintechs asking you about these days regarding agentic authority, if you can explain a little bit?

Jeremy Blackburn: Yeah, it's an interesting period of time we're moving into. We're definitely in the peak conference season here, with payment conferences and fintech conferences, and as you mentioned, Money20/20 starts two days from now. I would say the vast majority of the companies and organizations, banks and fintechs, that are reaching out to ChainIT are all about agentic authority and compliance. Agentic commerce is the buzzword of the day. And I think that ChainIT has clearly established itself as the leader in agentic authority and commerce, which includes compliance.

What we're having conversations around is the guardrails I just described. How do we establish authority for individuals inside the organization? And let's be honest, that hasn't been done well historically. One of the key components of ChainIT is Pactum, which is contract, and Veritas, which is truth. So it's a contract of truth, or a true contract. Inside of Pactvera, which is our commerce platform, our contracting platform, we never allow for self-attestation of authority. If you're transacting on behalf of a business, you have to have authority from the owners, to the officers, to you, to actually even bind the organization.

You see this all the time with current digital signature platforms sending documents: click here. We have a whole series of videos on YouTube modeled after a dog named Spoof. The reality is that if it's just a click-the-button signature, there's no way to prove that the person who clicked that button had authority, or even to prove that they are who they say they are. In those videos, the dog literally walks across the keyboard, hits enter, and that signs a contract. And then it sets off a whole chain of events that we document.

It happens often. There have been some legal challenges to current e-signature platforms because it's very difficult to prove who actually clicked that document. You can prove an IP address. You can maybe prove an email. But who actually opened the email? I have several people, assistants and team members, who have access to my email. My agent has access to my email. How do you know that I actually signed that document if all it requires is a click?

Inside of ChainIT, nothing is clicked and nothing is typed. It is biometric attestation. You're scanning your face, and your biometric confirmation then validates that you are who you say you are. We then do that real-time check for authority, and even compliance, for agreements. And I think the value of that is coming to the forefront of all business, and especially financial transactions. How do you know that the person who executed that agreement is who they say they are, that they actually executed it, and that at the time they executed it, they had authority? And if there's money involved, that the compliance was satisfied?

So I would say 95% of all of our conversations now are not just about identity, tokenization and stablecoin. They're about complete commerce. How do we move our business into this world of complete commerce that involves agentic? I don't think we've met with anybody in the last three months that doesn't have a roadmap or a plan to include AI or agentic commerce in their future. And ChainIT is able to offer that: the rails, the guardrails, and the verified authority and compliance confirmation at runtime.

We didn't really talk about that much previously; I omitted that by accident. But the reality is that when you create your individual ID or your organizational ID, it's not a static thing. It's an appendable data field. So every time you conduct a transaction, and it might be an amount that triggers it, if we need to do compliance again or authority again, we do that again at runtime. In other words, we're verifying that you are still listed as an employee in that company's ledger and that your authority hasn't been revoked. In other words, you didn't get fired yesterday, or you didn't get reassigned to a different department.

Maybe you were the receiving clerk, so you were receiving shipments, and now you're the shipping clerk. A truck pulls in, you go over there, and they're about to receive it. You don't have that authority anymore, because your job title has changed. Well, ChainIT does a real-time check to make sure that whoever is verifying the receipt on behalf of the organization has the authority to do it at the time of the transaction. So the ability for ChainIT to be this truly connected, verifiable digital verification layer, the infrastructure, is, I think, the majority of the conversations we're having.

37:16Where to learn more

Dr. Med Mehrbod: Got it. Jeremy, thanks a lot for walking us through this. I personally learned a lot, and I hope our audience also learned. For people who are not familiar with ChainIT, where can they go to check out ChainIT? I know there's a lot going on right now. What are your recommendations?

Jeremy Blackburn: Yeah, we've got a lot of pilot projects, several of which have actually wrapped and are going through full integration now. A lot of those companies are public companies, so I know they'll be issuing press releases in the near future. Look forward to those. We also have a website, chainit.com. A lot of the individual products in ChainIT have their own websites and environments, like pactvera.com. We're on LinkedIn, and we have white papers, press releases, things of that nature.

The next part of commerce isn't a payment rail or a payment method. It really is authority: the authority, and the ability to prove authority at runtime. I believe that's where the industry is heading, and I think that's the infrastructure that ChainIT has built and provides.

Dr. Med Mehrbod: Authority and the ability to prove authority, guys. All right. Thank you so much, Jeremy, for joining me today. And thank you to everyone for tuning in to Elementera Talk. Talk later.

Jeremy Blackburn: Yep. Thanks, Dr. Med. All right.