{"id":"1153a1ad-a09a-4926-afa1-4c31167a162d","arxiv_id":"2608.13030","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"InterSAGE defines a four-layer trust protocol that combines persistent agent identity, verifiable capability discovery, monotonic delegation, and kernel-signed audit trails for Internet-of-Agents interoperability.","lead":"InterSAGE is a proposed trust layer for the emerging Internet of Agents, giving AI agents verifiable identity cards, signed capability claims, bounded delegation, and tamper-evident audit logs. It matters because today's agent protocols define how agents talk, not how they prove who they are or what they may do.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Delegation step contradicts the AIC signature definition, so the GAR-rooted trust chain is not actually specified for delegated agents.","rationale":"The reader identified GAR honesty as the weakest assumption, which is a real and acknowledged trust boundary. My concern is different and more specific: the formal object at the root of Layer 0 is internally inconsistent. Section 4.1 fixes all AICs as GAR-signed credentials, while Section 6.2's delegation protocol describes child AICs as signed by the parent key. The delegation chain is one of the four layer-aligned primitives, and the joint-enforcement claim depends on it. If child AICs are parent-signed, then the GAR-rooted verification story in Sections 5.4 and 8.2 needs revision; if they are GAR-signed, the protocol text omits a required step. Because the paper explicitly defers formal verification, implementation, and adversarial testing, internal consistency of the protocol description is the main available evidence. This inconsistency does not move the verdict: the paper remains a plausible positioning proposal whose strongest claims should be treated as design intent rather than established result. The same condition already stated by the reader—formal verification and an implementation—would also force this ambiguity to be resolved. I therefore leave the CONDITIONAL verdict unchanged, with the added note that the delegation/AIC signature question should be among the first items checked in companion work.","tokens_in":27254,"tokens_out":6048,"duration_ms":67740,"concrete_test":"Write out the verification relation for a two-hop delegation P -> C using Equation (1) and Section 6.2 step 6. Concretely: with only the GAR root public key and P's AIC, can an independent verifier validate C's AIC? If not, then the Section 8.2 statement that chain verification walks to the GAR root is false as written. As a second check, ask the authors to provide a machine-readable AIC schema for the companion implementation and inspect whether child AICs carry a GAR signature or only a parent signature. If only parent-signed, amend Equation (1) and Section 8.1, or weaken the joint-enforcement claim for delegated agents.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that InterSAGE jointly enforces persistent identity and trust negotiation depends on every AIC, including delegated child AICs, verifying against the GAR root. Section 4.1, Equation (1), defines AIC = Sign_GAR(DIDagent || Kpub || Smax), and Section 8.1 assumes GAR honesty for AIC issuance. But Section 6.2, delegation protocol step 6, says 'GAR issues child AIC signed by the parent's key.' If that is literal, child AICs are not GAR-signed: verification of a delegated agent's identity requires the parent's public key, and the statements in Section 8.2 that chain verification 'walks to the GAR root' and in Section 5.4 that discovery verification checks manifests against the AIC trust chain are not defined for delegated agents. If the intended meaning is that GAR signs after the parent authorizes, then the text omits that GAR signature, and the formal model in Equation (1) is incomplete. Either way, the strongest claim—that these four properties are jointly enforced as a single trust substrate—overstates what the protocol text actually specifies. This is not an external attack like GAR compromise; it is an internal inconsistency in the credential form that the security analysis relies on, and it sits at Layer 0, on which all other layers depend.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes InterSAGE, a four-layer trust protocol suite for the Internet of Agents. Layer 0 provides persistent agent identity through Agent Identity Cards (AICs) that bind developer, code package, operator, and operational context, signed by a Global Agent Registry (GAR). Layer 1 offers capability-aware discovery via DID-bound Verifiable Credential manifests. Layer 2 provides trust negotiation through mutual attestation, delegation with monotonic capability attenuation, and two-tier access control. Layer 3 supplies kernel-mediated cryptographic audit trails for accountability. The paper positions InterSAGE as complementary to MCP, A2A, ANP, and AG-UI, and argues that no prior architecture jointly enforces persistent identity, capability-aware discovery, trust negotiation, and accountability as a single trust substrate. The manuscript is explicitly a positioning paper: formal proofs, performance evaluation, implementation details, and adversarial validation are deferred to companion work (§10.1).","tokens_in":27508,"tokens_out":3093,"duration_ms":31560,"significance":"If the protocol were fully specified and formally analyzed, InterSAGE would address a genuine gap in agent interoperability: most communication protocols do not define agent-native identity, capability verification, or non-repudiable audit. The paper's threat model (Table 1) and design principles (§3.1) are thoughtful, and Table 7 makes the joint-coverage argument explicit and checkable. The authors also deserve credit for clearly delimiting the paper's scope in §10.1 and for avoiding overclaiming on implementation maturity. However, the central novelty claim—that InterSAGE is the only architecture jointly enforcing the four properties—rests on qualitative self-assessment in Table 7 and is weakened by internal inconsistencies in the credential definitions and by the mismatch between the 'we prove' language in §8.2 and the deferral of formal verification in §10.1.","major_comments":[{"comment":"The AIC definition in Eq. (1) states that an AIC is Sign_GAR(DIDagent || Kpub || Smax), so every AIC is GAR-signed and verification walks to the GAR root. However, the delegation protocol in §6.2, step 6, says 'GAR issues child AIC signed by the parent's key.' If this is literal, child AICs are not GAR-signed, and the statements in §8.2 that chain verification 'walks to the GAR root' and in §5.4 that discovery verifies manifests against the AIC trust chain are undefined for delegated agents. If the intended meaning is that the parent authorizes and the GAR then signs, that GAR signature is missing from the protocol text and from the formal model in Eq. (1). Either way, the delegation primitive—a core component of Layer 2—does not currently form a GAR-rooted trust chain as claimed, and this inconsistency sits at Layer 0, on which all other layers depend.","section":"§6.2 (Delegation Protocol, step 6) versus §4.1, Eq. (1)"},{"comment":"Section 8.2 opens with 'We prove that InterSAGE satisfies its core security properties under the defined threat model,' but the analysis that follows is a prose argument over definitions, not a formal proof. Section 10.1 explicitly lists 'Formal verification: TLA+ or ProVerif models of the attestation and delegation protocols' as out of scope, along with performance evaluation, implementation detail, and adversarial evaluation. The proof claim in §8.2 is therefore contradicted by the manuscript's own limitations statement. The security properties should be presented as design arguments or informal security analysis, not as proofs, or the relevant formal models should be included.","section":"§8.2 versus §10.1 (Limitations)"},{"comment":"The joint-coverage argument—the basis for the abstract's claim that InterSAGE is 'the only architecture' jointly enforcing the four properties—rests entirely on the qualitative marks in Table 7 (•, ◦, —) assigned by the authors to selected comparators. The table gives no citations, definitions of the evaluation dimensions, or justification for each mark. For example, AgentMesh is marked '◦' for '4-dim binding' and '—' for 'verifiable manifests,' but the text does not explain which of AgentMesh's mechanisms were examined to reach these conclusions. Without a clear evaluation rubric or at least per-cell justifications, the 'only architecture' claim is not substantiated. The authors should either supply a detailed scoring methodology with evidence for each cell or weaken the novelty claim to 'none of the surveyed comparators provides all four primitives in our sense.'","section":"§9.8 and Table 7"}],"minor_comments":[{"comment":"In the first paragraph of §8.2, the credential is called the 'Agent Identity Credential' while everywhere else it is the 'Agent Identity Card' (AIC); please use consistent terminology.","section":"§8.2"},{"comment":"The term 'kernel' is used for both a general secure key-custody component and the specific 'DeepKernel' product. Since the paper describes a protocol suite that is not tied to DeepKernel, clarify that 'kernel' refers to any compliant key-custody component and that DeepKernel is one implementation.","section":"§4.4 and §7.3"},{"comment":"The table row 'PDP misconfigured to allow tools:*' lists InterSAGE as '✓' but the supporting argument depends on the assumption in §8.1 that the kernel correctly enforces delegation bounds and that the GAR correctly verifies bindings at issuance; please state these dependencies explicitly in the table caption or the surrounding text.","section":"§8.4, Table 6"},{"comment":"The phrase 'positioning paper' is used repeatedly; consider adding a sentence in the introduction that defines what a positioning paper means for the journal's audience, since the term may be unfamiliar.","section":"§10.1"},{"comment":"The text says 'both skills and tools are represented assigne Verifiable Credentials' (missing blank); please fix the typo.","section":"§5.4"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is a positioning paper with ambitious claims; its central 'only architecture' claim depends on Table 7, which is essentially the authors' own qualitative assessment with no external grounding. The delegation-vs-AIC inconsistency and the 'we prove' language are the two most serious technical issues. Authors should be encouraged to either provide formal models (matching §10.1's deferred list) or consistently describe the analysis as informal. I would also flag for the editor that many citations are to 2025–2026 arXiv preprints and to the authors' own prior work (BlockA2A); this is not disqualifying, but the novelty claim should be evaluated against the possibility that similar protocol proposals are published in the rapidly moving agent-identity space."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper is worth a read if you're tracking agent security, but keep the positioning framing in mind. It is explicitly a design proposal: no proofs, no implementation, no benchmarks. The interesting contribution is the conjunction of four known primitives—four-dimensional AIC identity, DID-bound manifest VCs, monotonic attenuation plus two-tier access control, kernel-mediated audit trails. The authors are unusually candid about the fact that each piece exists elsewhere; their Table 7 and the related-work section are actually useful as a map of the landscape.\n\nThe architecture is plausible and the writing is clear. The two-tier access control separating infrastructure-tier cryptographic checks from application-tier policy is a good idea, and the threat-model synthesis (T1–T6) is reasonable. As a positioning paper it does what it sets out to do.\n\nThe soft spots are real. First, §8.2 says 'We prove that InterSAGE satisfies its core security properties,' but the 'proofs' are prose arguments over definitions, and §10.1 explicitly defers formal verification, performance evaluation, and adversarial testing. That mismatch should be fixed—either soften the claim in §8.2 or move the proofs to a companion paper and say so. Second, the delegation chain is genuinely under-specified. Equation (1) defines an AIC as GAR-signed, but §6.2 step 6 says 'GAR issues child AIC signed by the parent's key.' If the parent signs, then child AICs do not inherit GAR-signed identity in the sense of Equation (1); if the GAR signs, the protocol omits that signature. Either way, the security-analysis claim that chain verification 'walks to the GAR root' needs a precise statement of the child-AIC form and its verification path. This is fixable with a few sentences, but as written the central claim overstates what the protocol text specifies. Third, the joint-coverage argument (only architecture that...) rests entirely on the authors' own Table 7, with qualitative bullets. That's fine as a positioning claim, but it is not evidence.\n\nWho is the paper for? Researchers and standards folks working on agent identity and delegation. It would be a useful design proposal to have on the table, and a serious referee could shape it into a cleaner protocol spec. I would accept it for review, with the expectation of major revision, not because the architecture is wrong but because the security claims need to be scaled to what is actually demonstrated.","headline":"A well-organized architectural position paper whose honest synthesis of known primitives is let down by security claims that outrun the evidence and a delegation step that is genuinely under-specified.","tokens_in":28070,"tokens_out":3622,"would_cite":true,"duration_ms":33298,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"InterSAGE is a four-layer trust protocol suite that lets agents prove who built them, what code they run, and what they did.","keywords":["agent identity cards","verifiable credentials","capability-aware discovery","monotonic capability attenuation","trust negotiation","accountability","internet of agents","delegation"],"falsifier":"Run an implementation, misconfigure the application-tier policy to request a capability outside the parent agent's signed maximum, and inspect the session token; if any token grants that capability, the structural least-privilege claim is false.","tokens_in":26997,"feed_emoji":"🔐","tokens_out":5943,"duration_ms":58751,"temperature":0.7,"pith_summary":"The paper argues that today's agent protocols standardize how agents exchange messages but not how agents prove identity, authorization, capabilities, or accountability, so the Internet of Agents lacks a trust plane. InterSAGE is proposed as that plane: four layers—persistent identity, capability-aware discovery, trust negotiation, and accountability—built on four primitives: Agent Identity Cards, DID-bound Verifiable Credential manifests, monotonic capability attenuation with two-tier access control, and kernel-mediated signed audit trails. If correct, InterSAGE would let agents verify each other's provenance and permissions before acting, keep delegated authority strictly shrinking, and attribute every action without relying on a blockchain. The paper positions InterSAGE as complementary to existing protocols, embedding trust primitives into their messages rather than replacing them.","feed_headline":"Four trust layers make agent identity and actions verifiable","feed_subtitle":"Signed identity cards and kernel audit trails secure agent-to-agent action without replacing existing protocols.","key_machinery":"The load-bearing object is the Agent Identity Card (AIC), a registry-signed credential $AIC=\\operatorname{Sign}_{GAR}(DID_{agent}\\|K_{pub}\\|S_{max})$ whose $S_{max}$ is the maximum capability set. Around it, the machinery is a four-stage monotonic attenuation chain—developer declaration, operator subset, registry issuance, runtime intersection—where every stage can only narrow, and a session boundary $S_{session}=S_{policy}\\cap(S_{A}^{max}\\cap S_{B}^{max})$. Skills and tools are carried as DID-bound Verifiable Credential manifests, and trace entries are signed by a kernel-held private key and linked by hashes. This machinery supplies the structural guarantees: subset checks and signatures, not runtime policy engines, enforce least privilege.","core_discovery":"InterSAGE's central claim is that no prior architecture jointly enforces persistent identity, capability-aware discovery, trust negotiation, and accountability as one four-layer substrate for agent interoperability. The Agent Identity Card binds developer, code package, operator, and deployment context into one GAR-signed credential, so an attacker who compromises one dimension cannot impersonate another. Discovery turns each advertised skill or tool into a signed credential bound to the agent's DID, verified for issuer provenance, subject binding, permission alignment, and freshness before interaction. Trust negotiation builds sessions as the intersection of both agents' signed capability boundaries, optionally narrowed by application policy, so a misconfigured policy can deny access but cannot grant more than the signed boundary. Accountability uses kernel-held signing keys and hash-chained trace entries to make execution history tamper-evident and non-repudiable without consensus.","pith_inferences":["The paper does not formalize this, but the attenuation chain suggests a lattice: if capabilities form a lattice under intersection and subset, the session boundary is a greatest lower bound, turning the structural claim into a provable invariant.","Because Layer 0 identity is independently useful, the protocol could bootstrap through partial adoption: issuing identity cards first, then layering discovery and negotiation as the population grows.","If the four-dimensional binding holds against operator compromise, audit systems could use AIC dimensions to separate 'authorized action within bound' from 'policy error', a distinction current logs blur.","The design leaves room for behavioral attestation as an additional signal rather than a rival: structural capability bounds could be combined with runtime trust scoring, with each covering what the other lacks."],"forward_implications":["MCP tool invocations can carry the caller's AIC capability boundary, letting a tool server verify authorization before execution.","A2A and ANP discovery responses can embed signed skill and tool manifests, so discovery results are verified rather than self-declared.","Session tokens issued after mutual attestation are scoped to the intersection of both parties' signed capability boundaries, so a misconfigured application policy cannot widen access.","Delegation chains are cryptographically bounded in depth and capability, with revoking a parent invalidating all descendants.","Kernel-signed, hash-linked execution traces give non-repudiation without a distributed ledger, which would extend to edge and air-gapped deployments."],"supporting_citations":[{"why":"Defines the agent-to-tool protocol whose tool invocations are the host messages that InterSAGE's Layer 0 capability boundary attaches to.","marker":"[7]"},{"why":"Defines the agent-to-agent protocol whose Agent Cards and task delegation provide the host messages that InterSAGE Layer 2 session tokens scope.","marker":"[6]"},{"why":"Uses W3C DIDs for agent discovery, the baseline that InterSAGE Layer 1 augments with signed manifest VCs.","marker":"[8]"},{"why":"Agent-to-user event stream that InterSAGE Layer 3 proposes to attach identity-signed execution traces to.","marker":"[31]"},{"why":"Primary industry comparator: a single-plane trust overlay that binds workload identity and enforces least privilege through runtime policy rather than issuance-time attenuation.","marker":"[19]"},{"why":"Closest academic comparator: a unified zero-trust architecture that adds behavioral attestation rather than structural capability bounds.","marker":"[20]"},{"why":"Closest delegation competitor that uses per-hop Datalog policy evaluation for capability tokens; InterSAGE's attenuation is set-intersection plus signatures.","marker":"[21]"},{"why":"The authors' prior blockchain-anchored trust framework that InterSAGE generalizes by removing the consensus-ledger dependency.","marker":"[23]"}],"fun_headline_variants":["InterSAGE: verifiable trust without replacing agent protocols","Four trust primitives for secure agent interoperability","Agent identity, capability discovery, negotiation, audit in one","Kernel audit trails bind agent actions without consensus","Signed capability boundaries and audit trails for agents"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The protocol assumes that the central registry's signing key is never stolen or misused and that the registry honestly checks a developer's and operator's claims before signing an identity card; all other guarantees trace back to that one signature.","fun_headline_variants_meta":{"raw":{"variants":["InterSAGE: verifiable trust without replacing agent protocols","Four trust primitives for secure agent interoperability","Agent identity, capability discovery, negotiation, audit in one","Kernel audit trails bind agent actions without consensus","Signed capability boundaries and audit trails for agents"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000909,"raw_usage":{"total_tokens":3920,"prompt_tokens":972,"completion_tokens":2948,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":588,"completion_tokens_details":{"reasoning_tokens":2875}},"tokens_in":588,"tokens_out":2948,"duration_ms":22041,"temperature":1.0,"reasoning_tokens":2875,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T18:10:14.182364+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run an implementation, misconfigure the application-tier policy to request a capability outside the parent agent's signed maximum, and inspect the session token; if any token grants that capability, the structural least-privilege claim is false.","supporting_citations":[{"cited_title":"Model context protocol (MCP) specification.https://modelcontextprotocol.io/, 2025","cited_arxiv_id":null,"evidence_quote":"Defines the agent-to-tool protocol whose tool invocations are the host messages that InterSAGE's Layer 0 capability boundary attaches to."},{"cited_title":"Agent-to-agent (A2A) protocol specification","cited_arxiv_id":null,"evidence_quote":"Defines the agent-to-agent protocol whose Agent Cards and task delegation provide the host messages that InterSAGE Layer 2 session tokens scope."},{"cited_title":"AG-UI: The agent-user interaction protocol","cited_arxiv_id":null,"evidence_quote":"Agent-to-user event stream that InterSAGE Layer 3 proposes to attach identity-signed execution traces to."},{"cited_title":"AgentMesh: Production-grade trust layer for multi-agent systems","cited_arxiv_id":null,"evidence_quote":"Primary industry comparator: a single-plane trust overlay that binds workload identity and enforces least privilege through runtime policy rather than issuance-time attenuation."}],"review_version":1}