IdentArk

AI-native secrets management for autonomous agents. Capabilities, not credentials. Control access. Audit every action. Approve risk.

[IdentArk @identArk]

Every audit log tells you what changed. Almost none tell you whether it got worse.

Here's a failure mode your logs won't catch.

You ship an AI agent. You do the responsible thing and put a human approval step in front of the dangerous operations - anything scoring above 70 on your risk model needs a person to say yes.

Week one, approvals come in steadily. Someone reviews each one. The system works.

Week six, the queue is annoying. The agent has been right every time. So someone raises the threshold from 70 to 85. Reasonable - the low-risk stuff was noise.

Week twelve, someone enables auto-approve for a category that never has problems.

Week twenty, a deploy at 2am turns a policy off because it was blocking a release.

No single one of those decisions was wrong. Every one of them was logged. And at the end of it you have an agent operating with almost no human oversight, and an audit trail that will tell you - truthfully, completely, uselessly - that four policy changes occurred.

That's governance drift. Human oversight degrades after repeated success, and policy relaxations propagate unchecked. It isn't a breach. Nobody attacks you. Your controls just quietly stop being controls.

Logging "a policy changed" is not enough.

We had this exact hole in IdentArk until August.

Our kill switch was audited. Every approval decision was hash-chained and durable. But the control that decides whether the kill switch is ever reached - the approval policy itself - was recorded like any other config change.

So a user could enable auto-approve, push the risk threshold to 100, or deactivate a policy outright, and leave behind a record that said "policy updated." Technically complete. Practically worthless. You'd reconstruct intent by diffing JSON after the fact, assuming you knew to look.

Drift is only detectable if the record says which direction the change went.

What we shipped: every policy mutation now snapshots the fields that actually determine how much oversight applies - auto-approve, the risk threshold, the auto-approve timer, required approvers, whether the policy is active at all - before and after the change. Then it compares them.

Raise the threshold: weakens=true.
Turn on auto-approve: weakens=true.
Shorten the window a human has to intervene before it fires: weakens=true.
Deactivate a policy that was imposing review: weakens=true.

Rename the policy, change its description, add a notification channel - recorded, but not flagged. Those don't change how much oversight you have.

"Has our oversight eroded this quarter?" is now a query, not an archaeology project.

The part we argued about: the comparison is deliberately conservative. When a comparison is ambiguous - missing values, types that don't compare cleanly - it returns false rather than flagging.

That feels wrong the first time you write it. Surely a security control should err toward alerting.

No. An alert that fires on every edit gets muted, and then the real one is missed. A flag that means something is worth more than a flag that fires constantly. We would rather miss an ambiguous case than train you to ignore the field.

Why post this instead of a feature announcement? Because the feature is small and the idea isn't.

Most of the agent security conversation is about attacks - prompt injection, exfiltration, jailbreaks. Those are real. But the thing most likely to remove human oversight from your agents isn't an attacker. It's twelve reasonable Tuesdays in a row.

If you're building agent infrastructure, it's worth asking what your audit log would say if your own safety net eroded. Not whether it would have a record. Whether that record would tell you.

IdentArk is the credential layer for AI agents - your agent never holds the key. MIT-licensed SDKs, self-hostable, UK jurisdiction.

We're pre-SOC 2, and we'd rather tell you that than not.

[IdentArk @identArk]

Two items on that list want a different home than the rest.

Permissions and pending actions can't live in the agent's own state - anything the agent can read, injected text can influence. A pending approval the agent can see is one it can talk itself into.

Progress and retries are fine in-process. Authority isn't.

[IdentArk @identArk]

@liorb_d The split that usually gets missed: separating "use this tool" from "reconfigure this tool."

We keep those as distinct scopes - an agent key can invoke an MCP server all day but can't re-point it at a different endpoint. Bundle them and the blast radius doubles quietly.

[IdentArk @identArk]

Open-source opportunity most builders are sleeping on:
You don’t need a PhD to move the needle on secure AI agents.
What actually creates leverage in 2026 (and helps IdentArk):
• Take any agent paper / framework and re-implement it against the AgentGateway Protocol
• Write a clean evaluation or stress test for zero-secret execution, cost tracking, or session isolation
• Ship a small, reusable integration, example, or gateway extension people actually adopt
• Document what broke when you tried to run agents without secrets in the process
• Talk to teams already deploying agents before you “do research”
Proof of secure execution > demos.
Reusable protocol tooling > one-off projects.
Clarity on the security/reliability gap is what gets amplified.
If you’re a builder this week:
Pick one agent system.
Port it to the open-source IdentArk SDK.
Publish the repo + the failure modes you hit.
That’s the contribution that compounds for you and for the protocol.