Evaluate the new PolicyArc release with a synthetic AI-agent workflow, scoped access, consent checks, expiry, revocation and auditable negative tests.
What changed and who can use it
IDENTOS announced PolicyArc general availability on October 20, 2026. The company says security, platform and compliance teams can define, enforce and audit access policy across connected applications, including scoped and time-limited access delegated to an AI agent.
The release describes per-request consent checks and decisions that combine standing identity facts with real-time context to allow, deny or request extra verification. It also says access can end automatically with the task or time window and that decisions are logged. These are vendor claims; DeepSecurity did not independently test the product.
A focused Firecrawl search on October 24 found the dated official release and independent same-day coverage. That verifies recency and current coverage, not adoption, performance or market leadership. Public pricing, plan restrictions and detailed connector compatibility were not stated in the reviewed pages; confirm those items with the vendor before designing a rollout.
1. Choose one synthetic, reversible workflow
Start with a non-production task such as allowing a synthetic support agent to read one mock case and append one test note for 15 minutes. Use synthetic identities and data, a disposable resource and an application with complete request logging. Do not begin with production customer records, payments, infrastructure changes or broad search.
Write the policy contract before integration: human principal, agent identity, delegated purpose, allowed action, exact resource, consent record, start and end time, context requirements, step-up condition, denial behavior and rollback owner.
The expected output is a small set of explicit decisions and evidence, not a demonstration that an agent can “do everything.” A bounded first task makes failures visible and rollback cheap.
2. Map policy inputs to a decision record
Confirm how the integration represents the human, agent, task, resource and requested action. Decide which facts are authoritative and how consent, sensitivity, workflow stage, device or session risk and time enter the evaluation. Do not let the agent supply untrusted context as if it were verified.
For each request, retain the policy version, normalized subject and agent identifiers, resource and action, relevant context, consent reference, decision, reason and timestamp. Keep sensitive content out of logs; store stable references where possible.
Ask the vendor to document failure behavior when the policy service, consent source or context provider is unavailable. For a sensitive action, fail-closed is usually safer, but the application owner must explicitly choose the availability tradeoff.
3. Prove the deny, expiry and revocation paths
Run the exact allowed task, then deliberately vary one dimension at a time: a broader resource, an unapproved action, a missing consent record, a time after expiry and an explicitly revoked delegation. Confirm the application enforces each denial and the audit record explains why.
Test an in-flight task when consent is revoked and when the access window expires. Determine whether the next request is denied, whether cached sessions remain usable and how long policy changes take to propagate. Do not assume “automatically revoked” means every downstream token disappears instantly.
Expected output: a matrix of request, expected result, observed result, decision reason, timestamp and reviewer. A passing happy path without negative tests is not evidence of least privilege.
4. Compare audit evidence with the source systems
Reconcile PolicyArc decisions with application, identity-provider, consent and data-access records using correlation identifiers. Confirm an allow created only the intended action, a deny produced no side effect, and an expired or revoked lease could not reuse a cached downstream credential.
Suggested review prompt for an approved assistant: “Using these sanitized decision and application records, match requests by correlation ID. List expected and observed results, missing records, timing gaps and contradictions. Cite every source row. Do not infer that a missing event means no access occurred.”
Have a human reviewer inspect samples and every contradiction. Audit completeness, retention, export, tenant separation and tamper resistance should be explicit acceptance criteria rather than assumed from an “audit trail” feature claim.
Roll out in gates—and know the limits
Move from a synthetic lab to shadow evaluation, then one bounded production workflow only after identity mapping, negative tests, availability behavior, evidence export and rollback meet the written criteria. Keep existing authorization in control until the comparison is acceptable.
Before purchase or production, verify pricing, licensing, supported protocols and applications, regional data handling, service-level commitments, administrative roles, policy-change approval, incident response and export portability directly with IDENTOS. The public release reviewed here does not establish those details.
PolicyArc can centralize delegated authorization, but it does not determine whether an agent’s task is safe, stop prompt injection inside the application or replace data classification, tool restrictions and human approval for high-impact actions.
- Begin with one synthetic task, one resource and a short access window.
- Test broader scope, expiry, revocation, missing consent and dependency failure.
- Require correlated application and policy evidence before expanding.
Put the insight into practice.
Deep Security helps organizations assess risk, validate controls, and build a practical plan to strengthen their defenses.
Talk with Deep Security