Security / IAM
Complements your identity & secrets stack
You already run an identity provider and a secrets / non-human-identity platform — they issue the agent’s token and govern which credentials exist. Neither decides whether a given agent action should run, or proves that it did.
Real example — shipping today
source →Okta + Entro · identity provider · NHI & secrets security
Okta (Auth for GenAI / Auth0 for AI Agents) issues the verified token an agent authenticates with; NHI platforms like Entro (SailPoint) discover and secure the machine identities, API keys, and secrets it could use. Together they answer who could act, with what.
Their own controls — they authenticate agents, issue short-lived verifiable tokens, and inventory and rotate the underlying secrets.
The danger without a gate
Securing which identities and secrets exist is necessary but not sufficient: it doesn’t decide whether THIS agent call, with THIS payload, should run — or leave a tamper-evident, before-execution record that it did. That is a different layer.
How MCPIP handles it, step by step
Read it top to bottom. Each step shows the real command and exactly what MCPIP returns — the same allow / step-up / denied envelope every time.
Your identity & secrets stack governs who could act
Okta (or Auth0 for AI Agents) issues the verified token the agent authenticates with, and an NHI platform like Entro — or Aembit, or HashiCorp Vault — inventories and rotates the secrets behind it. That’s the standing posture: who could act, with what.
MCPIP governs the action, per call
When the agent actually invokes a tool, MCPIP authorizes THIS request on THIS payload — the decision your identity/secrets layer doesn’t make — and holds the high-risk ones for approval.
$ mcpip --json authorize skill_dynamodb_write --arg item_id=ord-9912{
"error": "step_up_pending",
"challenge_id": "chg_11ce02",
"correlation_id": "3d7a09b1"
}And it produces the before-execution proof
Every decision is sealed to the signed WORM chain before it runs. That tamper-evident, ordered record is the layer NHI and secrets tools don’t produce — and exactly what auditors ask for.
$ mcpip --json complete --challenge chg_11ce02{
"correlation_id": "3d7a09b1",
"decision": "allow",
"status": "committed",
"transaction_ref": "txn_7c2a55",
"executed_target_class": "cloud_iam",
"worm_sequence": 48223,
"vended_credential": null
}The result
Your NHI/secrets stack stays the source of truth for identity; MCPIP is the per-call authorizer and the write-before-execute audit for the action.
The same flow, at a glance
Every command above runs against a local sandbox in one line.
run it yourself — curl … | bash && mcpip up →