SentinelSCA

Security checkpoint for autonomous AI actions. Verify who is acting, what they intend to do, whether they’re authorized, and preserve evidence of what happened.

[SentinelSCA @SentinelSCA]

I once asked ChatGPT to clear one small thing.
It cleared everything I had built in that department. It took me 6 to 7 hours to get it all back.

It understood the task. It just did far more than I asked.

That memory came back this week. Boardy set up a call for me with Edwin Plange, another solo founder here in Ghana. He is building KasaFlow, an AI commerce engine that runs on WhatsApp. We are on almost the same Python and FastAPI stack, and Boardy's read was that we were fighting the same problem from two different ends.

Edwin said something I keep coming back to. Sometimes the AI understands exactly what the customer means and still gives the wrong output.

That is my ChatGPT story in one sentence.

The models are already good at understanding us. Where I lost 7 hours was the step after that, when the understanding turned into an action nobody had approved.

If I work in your company, I might be capable of a lot of things. That does not give me permission to do all of them. I need to be governed. An AI agent should work the same way.

That is what I have spent the last 9 months building Sentinel SCA for. Right before an agent does something consequential, Sentinel checks the action against the capability and policy that agent was actually given.
If it fits, it goes through.
If there is a real conflict, it goes to a person for review.
If the agent is doing something it was never assigned, it is denied.

We are still early and in active validation. But I know exactly what it feels like to spend an evening rebuilding work because an assistant was trying to help.

It understood exactly what I asked. It still cleared everything.

What is the biggest thing an AI tool has overdone for you on a simple request?

Sentinel SCA. Authority before action.

[SentinelSCA @SentinelSCA]

That sounds closely related to the boundary we’re focused on at Sentinel. The interesting question for me is how Cartha determines that authority at runtime: what evidence is evaluated, how narrowly the authorization is bound to the proposed action, and what prevents execution if that authority cannot be established.

I’d be interested in comparing the two approaches at that boundary rather than assuming they solve the same problem.

[SentinelSCA @SentinelSCA]

AI agents are getting easier to build.
Giving them authority over production systems is the harder problem. A prompt saying “don’t modify production data” is an instruction to the model. It is not an execution boundary. Once an agent can call tools, write to databases, invoke MCP servers, or trigger downstream workflows, the important question becomes:
What exact action is this agent authorized to perform right now? That is where runtime authorization starts.
A useful control chain looks more like:
Agent proposes action → authority is evaluated → exact permit is issued → executor verifies it → side effect occurs → evidence is recorded
The key distinction is simple:
Capability ≠ authority.
We’re publishing more of the engineering behind this at Sentinel SCA, including what we learned when stronger native-path testing exposed the difference between behavioral control and actual execution-bound enforcement.
https://t.co/5iYhYrjY1X?

#AIAgents #AIGovernance #AISecurity #EnterpriseAI #AgenticAI

[SentinelSCA @SentinelSCA]

Your AI agent works in testing.

Before giving it production access, ask:

What authority does it actually have?
What systems can it reach?
Is authorization bound to the exact action?
What happens after revocation or expiry?
What evidence survives execution?
Where does human oversight apply?
Can you explain the control boundary?

Capability ≠ Authority.

https://t.co/4bmR4XhS6S

[SentinelSCA @SentinelSCA]

That’s the part I’d want to be very careful with. If the system isn’t sure whether the first action actually completed, a restart shouldn’t quietly turn that into “try again.”

It should stay blocked until someone with the right authority reviews the evidence and confirms what really happened. Only then should another attempt be allowed.

[SentinelSCA @SentinelSCA]

That’s the right test. A receipt after execution isn’t enough if two executors can race the same permit, or if the action succeeds and the process crashes before the receipt is written. The durable boundary has to prevent double-consumption of the permit, and where the downstream system supports idempotency, the same execution key should bind all the way to the side effect.
If that guarantee isn’t available, the system should surface an uncertain/reconciliation state rather than pretend exactly-once execution was proven

[SentinelSCA @SentinelSCA]

Exactly. The permit has to bind to the action, not just the identity of the agent. For MCP, that means checking the specific server, tool, scoped arguments, actor, expiry, and replay/idempotency conditions at execution time, then recording both the authorization decision and the resulting side effect. Otherwise you still have a gap between “this agent is allowed” and “this exact action was allowed.” That gap is where a lot of risk hides.

[SentinelSCA @SentinelSCA]

@imryanarya007 https://t.co/wbeRj6z5gx

[SentinelSCA @SentinelSCA]

@avi11x https://t.co/wbeRj6yxqZ

[SentinelSCA @SentinelSCA]

@MalikAbdul94020 https://t.co/wbeRj6z5gx

[SentinelSCA @SentinelSCA]

@ananyairl https://t.co/wbeRj6z5gx

[SentinelSCA @SentinelSCA]

@patilprashhw https://t.co/wbeRj6yxqZ

[SentinelSCA @SentinelSCA]

@DEVIN__SETH https://t.co/wbeRj6z5gx

[SentinelSCA @SentinelSCA]

@imryanarya007 https://t.co/wbeRj6yxqZ

[SentinelSCA @SentinelSCA]

@Paixan_ https://t.co/wbeRj6yxqZ

[SentinelSCA @SentinelSCA]

The main change was shifting the question from “Did the agent understand?” to “Was this exact action actually authorized?”

That sounds subtle, but it changes where you put the control. The demo can pass, the model can understand perfectly, and the action can still be wrong. That is the boundary I’ve been tightening ever since.

[SentinelSCA @SentinelSCA]

I once asked ChatGPT to clear one small thing.
It cleared everything I had built in that department. It took me 6 to 7 hours to get it all back.

It understood the task. It just did far more than I asked.

That memory came back this week. Boardy set up a call for me with Edwin Plange, another solo founder here in Ghana. He is building KasaFlow, an AI commerce engine that runs on WhatsApp. We are on almost the same Python and FastAPI stack, and Boardy's read was that we were fighting the same problem from two different ends.

Edwin said something I keep coming back to. Sometimes the AI understands exactly what the customer means and still gives the wrong output.

That is my ChatGPT story in one sentence.

The models are already good at understanding us. Where I lost 7 hours was the step after that, when the understanding turned into an action nobody had approved.

If I work in your company, I might be capable of a lot of things. That does not give me permission to do all of them. I need to be governed. An AI agent should work the same way.

That is what I have spent the last 9 months building Sentinel SCA for. Right before an agent does something consequential, Sentinel checks the action against the capability and policy that agent was actually given.
If it fits, it goes through.
If there is a real conflict, it goes to a person for review.
If the agent is doing something it was never assigned, it is denied.

We are still early and in active validation. But I know exactly what it feels like to spend an evening rebuilding work because an assistant was trying to help.

It understood exactly what I asked. It still cleared everything.

What is the biggest thing an AI tool has overdone for you on a simple request?

Sentinel SCA. Authority before action.

[SentinelSCA @SentinelSCA]

That’s the gap I keep seeing too. A system can look impressive in a demo, but once you start depending on it for real work, you discover how much control and verification still has to be built around it.

I don’t think we should have to rebuild every tool from scratch just to trust what an agent is allowed to do. The surrounding authority layer has to become infrastructure, not smoke and mirrors.

[SentinelSCA @SentinelSCA]

@i_mika_el Exactly. Recovery matters, but prevention is the better control. The real shift is moving governance in front of the side effect: verify the exact action, scope, and authority before execution. Once the action has already happened, you’re in damage-control mode.

[SentinelSCA @SentinelSCA]

The main change was shifting the question from “Did the agent understand?” to “Was this exact action actually authorized?”

That sounds subtle, but it changes where you put the control. The demo can pass, the model can understand perfectly, and the action can still be wrong. That is the boundary I’ve been tightening ever since.